This the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

2016

What you do NOT need to do in Scrum!

What you do NOT need to do in Scrum!

2016 12 01 head

I often hear discussions asking who is performing the traditional product leader tasks in Scrum. This is in general an excuse to state that Scrum alone cannot work and classical product leaders are still needed.

Below a list of tasks you do NOT need anymore to do in Scrum.

  • Make commitments on behalf of the team about how much they can get done by a certain date or estimate effort for the team,
  • Coerce the team that the commitments made on their behalf are attainable,
  • Coerce the team to change their estimates,
  • Give direction to the team on how to implement the work,
  • Monitor the team’s progress to make sure they stay on schedule,
  • Step in and determine the solution,
  • Conduct weekly status update and face to face meetings with the team to surface issues and provide direction,
  • Provide motivation and push the team to work harder than they might want to use carrots and sticks,
  • Decide task assignments among the team members and follow up on tasks to verify completion. Force them to work during weekends,
  • Be responsible for the team doing the right thing at the right time in the right way,
  • Update Gantt charts for the iteration and release planning,
  • Finding out that requirements mean to explain team members what they should implement,
  • Review the documents and code to guaranty quality,
  • Explain upper management why the product is late and why you need additional resources,
  • Explain upper management why you cannot transfer a team member to another product,
  • Attend weekly progress and escalation meetings to explain in details the status of your product,
  • Define the priority of the next activities.

Now you as Scrum master or agile product manager have to perform important tasks

  • Help to remove impediments to increase velocity of team
  • Coach team to implement Scrum and reflect on their activities.
  • Plan-Do-Check-Adapt PDCA principle is built into Scrum with retrospectives and sprint reviews.
  • Coach product owner to deliver a groomed and refined backlog
  • Inform and support all product’s stakeholders
  • If you reflect on these two lists it becomes obvious that the first list describes malfunctions and the second one describes mechanisms how to improve continuously - lean principles -.

Jeff Sutherland gives some interesting insights about the Scrum master

  • The Scrum master enforces Scrum practices Coaching rather than command and control
  • The Scrum master effort is
    • Few problems: for a small team 10%, for a large team 50% of your working time,
    • Many problems: for a small team 50%, for a large team 100% of your working time until the team reaches a flow status,
    • A Scrum master is a change agent and supports the organization to become more agile.

I experimented with the Scrum master being part of the team, or Scrum master working for multiple teams. Experience has shown us that the full-time Scrum master is more effective.

And the LeSS framework has a clear rule about product managers

Keep product managers away from the teams!

Remarks

For all Project Management Institute +PMI_ fans, the institute has acquired Disciplined Agile Delivery DAD in 2019. The PMI-ACP is working on integrating agile approaches in the official PMI approach.

Found a Limited Liability Company in Switzerland

Found a Limited Liability Company in Switzerland

2016 11 02 head

I left the company I founded 20 years ago and needed a new home to work and have access to social insurances. I had to found a limited liability company with a capital of CHF 20'000.

Here the steps for the impatient.

Foundation

  1. Swissregistration wrote the statutes for the company and performed the foundation with certifying notary for CHF 780. Six hours after the first phone call they sent me the electronic documents. The next day the documents were delivered in paper form. It was really impressive.
  2. Before you can found a company you must deposit the capital to a special account. I choose Postfinance. It is a well-known Swiss institute and their fee is only CHF 145. They insisted I meet one of their collaborators to fill their forms – probably never heard about web forms -. I had bad luck and they needed three weeks to create the account and send payment confirmation. They were aware of the problem and very helpful but it still took three weeks.
  3. Upon reception of the payment confirmation, I sent all signed documents to Swissregistration. The next day the company was founded and I received the official paper documents a few hours later.
  4. I went to Handelsregisteramt Zug to register the company. They were very nice but told me they have a lot of work. Two weeks later they finally registered the company and sent me the papers and an invoice of CHF 780.
  5. A few phone calls later Postfinance converted the account into a regular account. They give me access to the founding capital minus their fee

During the waiting time I started to organise for the mandatory insurances you need in Switzerland

  • BVG – the best offer was from Axa Winthertur. They also help me because the company CRIF AG wrongly classified the activities of the new company. – They never contacted me and their NOGA classification has a huge impact on my costs. They are morons -
  • BU/NBU – the best offer was from Basler Versicherung When starting a software startup I suggest not concluding any other insurances

The government controlled social insurances contracts can only be initiated once the company is registered in the Swiss company registry. The AHV center needed more than two weeks to confirm my registration.

Lessons Learnt

  • The costs of founding my limited company in Switzerland is CHF 1'705 or 8.5% of the capital of the company.
  • The state owned companies and state services are very slow; in my case 20 times slower than the private ones. On the bright side their collaborators are very supportive.
  • Public or big private companies such as insurance firms are incapable to send documents or invoices electronically. They only use paper mail. Upon inquiry their collaborators told me their processes are incapable of handling modern communication ways.
  • Upon foundation you get pseudo-official letters from various companies to sell dubious services. Just throw them away.
  • The industry development office of Kanton Zug has no clues about start-up companies; the ones in Zürich and Luzern seem better.

Now we are ready to create great products with our customers

Please leave a comment if you know a better or less expensive way to found a Swiss liability company.

(the post was also published on LinkedIn)

What is an Agile Company?

What is an Agile Company?

2016 11 01 head

Lately people often ask me what is an agile company. They have an understanding of agile software development techniques such as Scrum, Lean, Kanban, eXtreme Programming but no clue how a company could be agile.

One way to approach this theme is to implement concepts of the above mentioned agile approaches. These are the pillars for iterative incremental improvements.

Scrum Pillars

Transparency
you trust all collaborators to provide their best when working on the product. They need full access to all relevant information: quality, progress, budget, people and financial data. They use the data to select the best alternatives to reach the company’s goals
Inspection
you cherish a failure culture because inspections will find weak points. You need a culture where people are never blamed. One consequence is that you eliminate management by objectives, and bonuses in your company
Adaptation
you are ready to learn better approaches and truly believe there is a better solution. Processes change regularly bottom-up, company’s budget can only be a rolling indicative budget, and planning has to be continuously updated

You can also pursue desirable attitudes or values of agile persons

Scrum Values

Commitment
as an employee you want to win, you are engaged. Every manager truly believes you work best to achieve the goals. If not, this manager made a mistake by hiring or keeping you
Courage
you are ready to say “I am wrong” because being wrong opens the door for improvement
Focus
you daily optimise the customers’ value and thrive for excellence. As a developer you do not work on projects, you work on excellent products. You provide value to your customers
Openness
you seek better ideas and ways of doing. Openness requires transparency and respect.
Respect
you truly respect customers, team members, collaborators, persons. In your team I will not hear any disrespectful comments about people

Modern Agile

The modern agile movement defines guiding principles

Make people awesome
Dedicated collaborators want to give their best. Give them a purpose, a goal, empower them and let them climb the mountain. Thriving persons need purpose, excellence and autonomy. They are happier, healthier and more productive.
Deliver value continuously
Maintain sustainable pace and stability, all divisions of the organisation should focus on customer value. At the end of the day successful products are the only reason you get your paycheck.
Make safety a prerequisite
People do their best in their daily work, you believe in McGregor Y theory. Trust them and support them to become excellent. You shall develop self-awareness to increase safety.
Experiment and learn rapidly
you make mistakes, you learn and increase continuously the delivered value. You have a learning culture, you inspect and adapt. You can react to new opportunities faster than competitors.

Self Assessment

The above concepts are comprehensible. How do you know if you are moving in the right direction. A few concrete tests help you find out if you are an agile department or company.

  • Be agile instead of do agile. Practice the above attitudes and do not just follow a checklist
  • Nobody micro-manages in your company
  • Feel accountable instead of be accountable. You want to improve, and your company as a natural part of the daily work.
  • Compliment every collaborator you are working with at least once a week instead of evaluating weaknesses and criticising people. o you lead by example?
  • No management by objectives - MBO - or bonuses are established in your company
  • Every collaborator has access to all company data, every collaborator can request process and tool changes. We favour Individuals and interactions over tools and processes
  • You want to be excellent in your work. You have a purpose and autonomy in your daily work
  • Team members take the decision to hire or to fire collaborators, not the department responsible or the human resources group. Think about collaborators selecting their leaders, about managers being servants, about information available to all collaborators
  • Can you say the most important one word Sorry, the most important two words Thank you, the most important three words I was wrong and the most important four words Can I help you? at least three times a week?

I truly believe that we all want a fulfilling job which improves our world. I cannot understand other reasons to spend 40 hours and more per week for something less valuable. Take the above principles and apply them to your daily work. There are universal values to establish a working atmosphere you are proud of.

I agree with all of you to desire a fulfilling job is only true if you earn enough money to pay your monthly bills.

Food for Thoughts

These ideas are not new. You can delve in empirical evidence and discussions in books written by business management professors, CEO, and passionate agile advocates. Below a list of mind openers (available as Amazon ebooks):

  • Reinventing organisations: A guide to creating organisations inspired by the next stage of human consciousness by Frederic Laloux,
  • Accelerate: Building strategy agility for a fast moving world by John P. Kotter,
  • Beyond budgeting: How managers can break free from the annual performance trap;
  • The Leader’s Dilemma: How to build an empowered and adaptive organisation without losing control; both books by Jeremy Hope,
  • Holacracy: the new management system for a rapidly changing world by Brian J. Robertson,
  • Deliver Happiness: A path to profits, passion and purpose by Tony Hsieh,
  • The Lean Startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses by Eric Ries,
  • Lean Novels
    • The Lean Manager: A novel of lean transformation;
    • Lead with Respect: A novel of lean practice;
    • The Gold Mine: A novel of lean turnaround; all three books by Freddy Balle,
  • The Lean Mindset: Ask the right questions by Mary Poppendieck,
  • Social Intelligence: The new science of human relationships, by Daniel Goleman
  • Management 3.0: Leading agile developers, developing agile leaders by Jurgen Appelo,
  • The Fifth Discipline: The art and practice of the learning organisation by Peter M. Senge,
  • Fearless Change: Patterns for introducing new ideas; More Fearless Change: Strategies for making your ideas happen; both books by Linda Rising,
  • Excellence Novels
    • Build to Last: Successful habits of visionary companies;
    • Good to Great: Why some companies make the leap… and others don’t;
    • How the Mighty Fall: And why some companies never give in; all three books by Jim Collins,
  • Google re:work blog.

(this post was also published on LinkedIn)

Git Branches for the Impatient

Git Branches for the Impatient

2016 07 01 head

You are working in a small collocated development team and decided to use branches to implement new features or fix errors. Here the cookbook to create, edit, merge and delete local and remote branches in Git (version 2.x). Git branches have two important qualities.

  • A branch is like an idea. Once you implemented the idea, feature or fix you just merge back to trunk and delete the branch,
  • The history of the branch commits is still visible upon deletion of the branch.

You should use meaningful names for your branch name and associated commit messages. Put the ticket number into the branch name and messages for future searches.

The described approach is optimal for small teams. The approach is compatible to pull requests if you introduce such a workflow later. You do not need pull requests when you are working collocated . I prefer pair programming and pair check-in sessions against the trunk.

For a short introduction how to start using Git in software projects see the blog Git Local Repositories for the Impatient.

Create the Branch

Create new branch feat_#42 locally

git checkout -b feat_#42

Create the remote branch with the same name and initiate tracking, assuming your remote uses the standard default name origin.

git push -u origin feat_#42

Work on the Branch

Add your changes and commit them regularly.

git commit -a -m “commit message describing activities for feat_#42“

Upon running the unit tests locally, push the changes to repository

git push

Now you can test the branch from the central repository and deploy it to your continuous integration pipeline environment.

Merge the Branch

Switch to master and synchronize with your remote repository, the -p parameter means --prune

git checkout master
git fetch --all -p
git pull

Merge to master. The option --no-ff will always keep branch information.

git merge --no-ff feat_#42

Or if you want a single commit for the complete branch.

git merge —squash —no-ff feat_#42

Push the changes.

git push

For advanced users you can first rebase your branch and squash superfluous commits before merging the branch back to trunk.

Delete the Branch

Delete the remote branch (also git branch -dr origin/feat#42_).

git push origin --delete feat_#42

Delete the local branch.

git branch -d feat_#42

You are done. Now you are ready to implement the next feature.

View local and remote Branches

If you want to view branches use the following commands for the local branches.

git branch
git branch --no-merged

If you want to view remote branches.

git branch -r
git branch -r --no-merged

Checkout remote Branch.

The -p parameter means --prune

git fetch --all -p
git checkout #feat_42

More Information

You can find a lot of information on Stack Overflow. Beware when reading the answers on Stack Overflow that Git commands have changed over time. Select new posts to find the best answers.

The nifty-gritty details can be found in the official Git documentation.

Warning:

Beware that for example gitolite does not support special characters such as # in branch names. Use them only in the commit messages.

These same characters work in bitbucket.

The Version of the Scrum Guide 2011

The Version of the Scrum Guide 2011

2016 06 01 head

The new version of the Scrum Guide written by Ken Schwaber and Jeff Sutherland is available since July 2011. The older version was published in May 2009. I found quite interesting the precisions about the Scrum Master responsibility.

I have often discussions with the customers and companies I coach about the responsibility of the Scrum Master.

Who is responsible for the introduction of the Scrum approach in the company?

Often people state that the management should spread Scrum in the company. Ken and Jeff have a clear idea who is in charge of this.

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He needs indeed senior management support but the Scrum Master daily job is to spread Scrum in the company.

Who should coach the product owner to write better backlog and clarify the vision?

The Scrum Master serves the Product Owner in several ways, including:

  • Finding techniques for effective Product Backlog management;
  • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  • Teaching the Development Team to create clear and concise Product Backlog items;
  • Understanding long-term product planning in an empirical environment;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.

The Scrum Master should also coach the product owner and support him in the long term planning, the communication of the vision and backlog management. The vision and goals of the product should always contain an overall planning frame. During the product empirical evidence will trigger revision of the milestones and product planning.

What is the meaning of done and a piece of potentially shippable product?

When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the Definition of Done for the Scrum Team and is used to assess when work is complete on the product Increment.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is working product, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their Definition of Done will expand to include more stringent criteria for higher quality.

The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be ““Done””, which means it must be in useable condition and meet the Scrum Team’s Definition of “Done”.

It must be in useable condition regardless of whether the Product Owner decides to actually release it.

So at the end of sprint all stories realized since the start of the product must be correct. Therefore you need automated acceptance tests to guaranty their correctness. The Scrum team must guaranty that at the end of each sprint all functions of the product work as specified and accepted by the product owner in the current and previous sprint reviews.

Higher quality is reached through extreme programming approach: test driven development, clean code, pair programming, pair check-in, coding dojo, static analysis tools.

Does Scrum consider long-term planning?

Yes it is a major activity performed by the Scrum Master and Product Owner. See the above point about the Scrum Master coaching the Product Owner. See if anyone states that long-term planning is not part of the Scrum theory you should challenge them and give them the Scrum Guide to read. What can be changed during a Sprint? Often customers have heated discussions what can be changed during a sprint. Here a clear statement.

During the Sprint: * No changes are made that would affect the Sprint Goal; * Development Team composition and quality goals remain constant; and, * Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

What is measured in a burn down chart?

Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.

The only relevant information is the amount of work still open and when this work will be completed. This is true for sprint, release and whole backlog burn-down chart. I am glad that these precisions were added to the new version of the Scrum guide. I simplify my daily work. I can now simply refer the official Scrum Guide to convince people how aspects of Scrum should be understood. The older version of the Scrum Guide is still relevant because it contains hints and best practices no more part of the new version.

Scrum Master is a full-time Role

Scrum Master is a full-time Role

2016 05 01 head

I am very happy we discuss in depth the role, responsibilities and activities of a good Scrum Master. I fully agree with Scrum advocates that Scrum Master is a dedicated full-time job.

I am also convinced a Scrum Master can support multiple experienced Scrum teams. The Large Scale Scrum framework LeSS states a full-time Scrum Master supports 1 to 3 teams.

I worked with quite a few Scrum Masters, Product Owners, and Scrum teams. My experience shows it is more productive and effective when the Scrum Master works full-time as (see white paper of Barry Overeem)

  1. a servant leader
  2. a coach
  3. a facilitator
  4. a teacher
  5. a mentor
  6. an impediment remover
  7. a change agent
  8. a manager (please restrain yourself)

He should not implement stories. A Scrum Master is under huge stress being a development team member and having to balance their Scrum Master responsibilities against the commitment of the sprint goals.

So you shall have full-time Scrum Masters. More important is that you have real Scrum Masters, and not only Scrum administrators who organize meetings and manage the Scrum board and burn-down charts. Scrum has always been a hands-on approach, to be successful in this you need to have a passion for getting your hands dirty.

Find out if you are a real professional Scrum master. Do you perform each sprint the top things a Scrum Master usually forgets to focus on?

  1. Do Gemba. Redefine career paths, incentives, organization to be more Scrum focused,
  2. Identify with the product owner and the development team missing product backlog items,
  3. State team issues not being discussed because they are too uncomfortable,
  4. Find out appropriate balance between end-to-end system tests and unit tests,
  5. Play back the team’s progress against the proposed release plan,
  6. Integrate all tests into the continuous integration, delivery and deployment,
  7. Coach team members to understand the benefits of refactoring, removing waste and focus on quality,
  8. Teach Kaizen. Coach team to peer review and continuously improve towards perfection,
  9. Teach pair programming on a daily basis,
  10. Expand with the team and the organization the definition of done. Beware it can trigger an organizational change.

I hope the discussion what a successful Scrum master does stay active. Avoid agile coaches not being Scrum masters, they are not doing Gemba and loose contact with the knowledge workers.

Read our what you do not need to do.

It is a huge gain for the Agile community that people and organizations understand that a Scrum master is a professional coach, teacher, mentor, and change catalyst.

Books for Persons interested in Agile Approaches

Books for Persons interested in Agile Approaches

2016 04 01 head

Often I am told that it is difficult to use Agile/Scrum approaches for brown field projects or for big projects or for distributed projects or for in other situations.

Interestingly these persons also state that the same problem exist for RUP/OpenUP, Waterfall model DIN XT, Swiss variant called Hermes.

Agile approaches are currently the standard for new projects and are thought in technical universities.

Scrum is the main agile method and state of the industry approach for the implementation of software projects.

To open the discussion and bring the discussion back to objective arguments I often recommend the following books

Big Projects and Distributed Projects

  • Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman and Bas Vodde, Addison-Wesley 2009 This book and the one below are a very extensive presentation about the challenges and trade-offs of big distributed agile projects. Don’t expect pre-cocked solutions but a tool set how to lead successfully such projects. Not always an easy reading but worth the effort
  • Practices for Scaling Lean and Agile Development: Large, Multi-side, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, Addison-Wesley 2010 See above for a review of the book
  • Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory, Addison-Wesley 2009 The seminal reference book how to blend testing with agile projects. Lisa Crispin and Janet Gregory provides insights and a proven track how to guaranty agile quality assurance and agile testing. A must-read book for everyone seriously developing agile projects
  • Agile Estimating and Planning, Mike Cohn, Prentice-Hall 2006 The seminal reference about estimating agile projects. The experienced readers will understand why Mike Cohn used the words estimating and planning instead of estimates and plan.
  • The Enterprise and Scrum, Ken Schwaber, Microsoft Press 2007 The work of one of the Scrum founders how a company can adopt Scrum. You should read the standard works of Scrum to understand the concepts.
  • Agile Project Management with Scrum, Ken Schwaber, Microsoft Press 2003 The work of one of the Scrum founders how Scrum influence product organization and management. You should read the standard works of Scrum to understand the concepts.

Brown-Field Projects

  • Refactoring Improving the Design of Existing code, Martin Fowler, Addison-Wesley 1999 How to implement continuous improvement on the code level. If you are not refactoring you are not agile.
  • Working Effectively with Legacy Code, Michael C. Feathers, Prentice-Hall 2005 Most of us work on existing code bases. Based on the above statement you have to find a way to unit test and refactor legacy code if you want to be agile.

Extreme Programming

  • Test Driven Development by Example, Ken Beck, Addison-Wesley 2003 How can a programmer be sure his code is working before and after refactoring
  • Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, Prentice Hall 2009 We are professional developers and uncle Bob shows how we should work
  • The Clean Coder: A Code of Conduct for Professional Programmers, Robert C. Martin, Prentice Hall 2011 Uncle Bob define what a professional developer is. I know quite a few developers shocked by his requirements

Agile and Lean Concepts

  • Lean Software Development, An Agile Toolkit, Mary & Tom Poppendieck, Addison-Wesley 2003 Classical work what lean development means
  • Implementing Lean Software Development: From Concept to Cash, Mary & Tom Poppendieck, Addison-Wesley 2007 The hand-ons how to implement lean approaches
  • Agile Product Management with Scrum: Creating Products that Customers Love, Roman Pichler, Addison-Wesley 2010 Requirement engineering done the agile way
  • Scrum and XP from the trenches: How we do Scrum, Henrik Knieberg, InfoQ 2007 Short book how to implement Scrum and XP in projects

Change Management

  • Fearless Change: Patterns for Introducing New Ideas, Mary Lynn Manns & Linda Rising, Addison-Wesley 2005 The introduction of Scrum and agile principles means change in the organization and the teams. Linda Rising shows how changes are introduced with success in existing organizations.

Books everybody should have read

  • Peopleware: Productive Projects and Teams, Tom DeMarco & Timothy Lister, Dorset House 1987 How to growth teams and lead successful projects
  • The Mythical Man-Month 2nd Edition, Frederick P. Brooks, Addison-Wesley 1995 The first version was published in 1975. The rules postulated by Brooks are still actual. Sad is that a lot of product leaders have no clue of these rules.
  • Becoming a Technical Leader: An organic Problem-Solving Approach, Gerald M. Weingartner, Dorset House 1986 How a gifted technical engineer can become a manager.
  • Slack: Getting past burnout, busywork, and the myth of total efficiency, Tom DeMarco, Broadway Books 2001 In one sentence, the tremendous difference between efficiency and effectivity.
  • The Dilbert Principle, Scott Adams, Harper Collins 1996 An entertainment presentation of all the mistakes companies are doing and still thinking they are smart
  • Death March: The complete Software Developer’s Guide to Surviving "Mission Impossible" Projects, Prentice Hall 1997 In my current coaching activities I still encounter departments where burnouts are common. Either these managers are criminals or so plain stupid that they cannot be held responsible. I am still unsure

I am curious about books you recommend for agile or other approaches. Just drop me an email or leave a comment.

PMI-ACP Certification

PMI-ACP Certification

2016 08 01 head

I learnt quite a few new acronyms and techniques when studying for the PMI-ACP certification program. In this post I collected these acronyms, some definition and the bibliography you should know before attending the examination. The main advantage of having it is that you no more need to argue with PMI certified product managers if agile is applicable to software projects.

The main interest of PMI-ACP certification is their collection of concepts taken from Agile, eXtreme Programming, Scrum and Lean.

It could worth your money to buy the book "The PMI-ACP Exam: How to pass on Your First Try", Andy Crowe, First Edition 2012. The book itself is not rocket science but it contains two hundreds questions which are similar to the ones you will encounter during the examination.

To get your 21 PDUs necessary for the examination you must attend a training course. I booked an online course at Simplilearn for a reasonable price. The content was reasonable. The test questions were good.

The renewal of the certification again requires PDUs. I took an online training in interesting areas such as coaching techniques, how to manage effective and efficient meetings or how to write good protocols. Some online videos of Mike Cohn also count for PDUs.

Chapter List

  1. PMI ACP eligibility, examination content
  2. Agile product management APM Framework, agile product lifecycle
    1. Envision,
    2. Speculate (During the Speculate phase, the product stories are delivered. This phase involves planning and delivering tested stories in a short iteration, constantly seeking to reduce the risk and uncertainty of the product.),
    3. Explore,
    4. Adapt,
    5. Close.
    6. Scope, Costs, Time
    7. The agile triangle: Value (releasable product), Quality (reliable, adaptable product), Constraints (cost, schedule, scope)
  3. People, Products and Processes
  4. Value, Quality and Constraints The five identified core risk areas for a product are: Intrinsic schedule flaw, Specification breakdown, Scope creep, Personnel loss and Productivity variation.
  5. Planning, monitoring, adapting
  6. Estimation in agile projects
  7. Communication on agile projects
  8. Analysis and design on agile projects
  9. Agile quality
  10. Soft skills for agile product leaders and negotiation
  11. Value based prioritization of requirements
  12. Managing risk on agile projects
  13. Metrics and charts on agile projects
  14. Agile value stream analysis
  15. Knowledge and skills
    1. Agile team members should be flexible and adaptable.

Bibliography

The examination reference list of PMI ACP is (the titles in italics are also part of the CAT reference list)

Agile Retrospectives: Making Good Teams Great, Esther Derby, Diana Larsen
  1. Agile Software Development: The Cooperative Game – 2nd Edition, Alistair Cockburn
  2. The Software Project Manager’s Bridge to Agility, Michele Sliger, Stacia Broderick
  3. Coaching Agile Teams, Lyssa Adkins
  4. Agile Project Management: Creating Innovative Products – 2nd Edition, Jim Highsmith
  5. Becoming Agile: …​in an imperfect world, Greg Smith, Ahmed Sidky
  6. Agile Estimating and Planning , Mike Cohn
  7. The Art of Agile Development, James Shore
  8. User Stories Applied: For Agile Software Development , Mike Cohn
  9. Agile Project Management with Scrum, Ken Schwaber
  10. Lean-Agile Software Development: Achieving Enterprise Agility, Alan Shalloway, Guy Beaver, James R

It is interesting to compare the above list with the reference list of the Certified Agile Tester CAT

  1. Agile Testing – A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory
  2. Succeeding with Agile: Software Development Using Scrum by Mike Cohn
  3. Agile and Iterative Development: A Manager’s Guide by Craig Larman
  4. Agile Project Management with Scrum by Ken Schwaber
  5. Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
  6. User Stories Applied: For Agile Software Development by Mike Cohn
  7. The Deadline by Tom de Marco
  8. Peopleware: Productive Projects and Teams by Tom de Marco & Timothy Lister
  9. Kanban by David J. Anderson
  10. eXtreme Programming explained: Embrace Change by Kent Beck

Terminology and Acronyms

The more terms and acronyms you know, the easier the examination will be.

2016 08 01 active listening

  • Active Listening
  • ARCS - Attention Relevance Confidence Satisfaction - relevant for motivational theory and process for systematic motivational design
  • Affinity Estimation - e.g. story points or teeshirt sizes -. The Affinity Estimating exercise is best conducted on Product Backlogs larger than 20 items. It is best when you have at least 40 items which allows for groupings to easily become apparent.
  • ATDD Acceptance Test Driven Development - Discuss, Distill, Develop, and Demo - see also Behaviour Driven Development BDD
  • Boundary, Authority, Role and Task BART
  • CD Continuous Deployment (CD as Continuous Delivery is not part of the examination)
  • Cumulative Flow Diagrams CFD
  • CI Continuous Integration: multistage integration is unning additional tests for performance, load or stability
  • Collaboration versus Coordination: Work Together versus Share Information
  • Cycle Time = Flow Time
  • DEEP Detailed Appropriately, Estimable, Emergent, Prioritised *Disaggregation: split story into smaller stories
  • DRY Don’t Repeat Yourself
  • EI Emotional Intelligence
  • EISA Emotional Intelligence Skills Assessment Perceiving, Managing, Decision Making, Achieving, Influencing
  • EQ Emotional Intelligence Quotient
  • Error-feedback ratio: is the number of new defects injected when fixing existing defects. Several years ago, Jerry Weinberg conducted studies on error-feedback ratio and found that a 20% difference in feedback ratio leads to an 88% difference in completion time (bad enough), but the next 10% increase leads to a 112% increase.
  • Earned Value Management EVM - this is standard PMI theory -
    • PV (Planned Value) = BAC (Budget At Completion) \* Planned Percentage Completed Budget Cost of Work Scheduled
    • AC (Actual Cost) - Budget Cost of Work Performed
    • EV (Earned Value) = BAC (Budget At Completion) \* Actual Percentage Completed - Sum (PV[Completed]) from start until current
    • CPI (Cost Performance Index) = EV / AC (Actual Cost) indicates if we are under or other budget
    • SPI (Schedule Performance Index) = PV / AC indicates if we are early or late
    • ETC (Cost Required) = (BAC - EV) / CPI - This metric is the forecast amount to complete the remaining work -
    • EAC (Forecast Cost for the total planned work) = BAC / CPI = AC + ETC
  • Five Level of Conflicts
    1. Problem to Solve (Good Teams) → Collaboration, consensus Collaboration- Seeking a win-win situation. Consensus- Learning where every team member’s head is with regard to the issue and, in time, arriving at a decision everyone can back.
    2. Disagreement → Negotiate, support
    3. Contest → Accommodate
    4. Crusade → Shuttle between parties
    5. World War → Protect to avoid injuries
  • JBGE Just Barely Good Enough
  • INVEST Independent Negotiable Valuable Estimable Small (Sized appropriately) Testable
  • Internal Rate of Return IRR, the higher the better. Internal Rate of Return (IRR) is used to express the return on product in % terms when comparing two different cash flow streams.
  • JIT Just In Time
  • Kano Model: Must have, Linear feature, Delight
    • Threshold or basic attributes are must have attributes otherwise the product is incomplete. Threshold features are those that must be present in the product for it to be successful. They are often referred to as must-have features.
    • Performance attributes are linear, the more the better
    • Excitement attributes are delights
  • MMF Minimally Marketable Feature
  • MoSCoW Must, Should, Could, Won’t
  • Net Present Value NPV → FV = PV * (1+i)^n, FV is future value, PV is present value, n is the number of periods/years, you can interpret as the higher the better
  • Payback Period, you can interpret as the lower the better
  • PESTLE Political, Environmental, Societal, Technological, Legal, Economical
  • PMI-ACP Project Management Institute Agile Certified Practitioner
  • Product Owner: Committed, Responsible, Authorized, Collaborative, and Knowledgeable
  • Project management methods
  • Relative Weighting Method
  • Retrospective: Set the stage, Gather data, Generate insights, Decide what to do, Close the retrospective
  • Risk
    • Risk Board
    • Risk Exposure (Risk Sensus) → Risk Probability * Risk Cost = Risk Exposure
    • Risk Management Process: Identify, Assess, Respond, Review of risks
    • Strategies: Avoid, Mitigate, Transfer, Accept
  • ROI Return On Investment (Benefits - Costs) / Costs in percent. The higher the better
  • ROTI Return On Time Invested (done in 60 seconds)
    • 0 = "I’d have been better off making a Starbucks run. Complete waste of time" or Lost Principle: No Benefit Received for Time Invested Break-Even
    • 1 = "You really should have let me stay at my desk and code"
    • 2 = "This was an OK meeting. About as valuable as if I’d been coding" or Received Benefit Equal to Time Invested High Return on Investment
    • 3 = "Surprisingly, this was more valuable than if I’d been writing code"
    • 4 = "Wow, this meeting saved me tons of time. Thank goodness I didn’t skip it to code" or Received Benefit Greater than Time Invested
  • RUP Rational Unified Process: Inception, Elaboration, Construction, Transition phases
  • Staging: The process of defining and prioritizing the nonfunctional requirements for scaling is called staging. Staging occurs prior to the start of the first sprint and takes just one day. During this day, the nonfunctional scaling requirements for this particular product are determined and placed in the Product Backlog.
  • Shu Ha Ri: can be considered as concentric circles, with Shu within Ha, and both Shu and Ha within Ri. The fundamental techniques and knowledge do not change.
    • "protect", "obey" — traditional wisdom — learning fundamentals, techniques, heuristics, proverbs
    • "detach", "digress" — breaking with tradition — detachment from the illusions of self
    • "leave", "separate" — transcendence — there are no techniques or proverbs, all moves are natural. Becoming one with spirit alone without clinging to forms; transcending the physical
  • Scrum
    • pillars: Transparency, Inspection, Adaptation
    • Scrum of Scrums = Meta Scrum
  • SDLC System Development Lifecycle
  • Servant Leadership
  • SIP Software In Progress
  • SMART - Specific Measurable Attainable Relevant Time-bound -
  • TFD Test First Development
  • Test Driven Development TDD
  • Extreme Programming XP
  • Wideband Delphi
  • Wave: Wave is the Product Planning structure with Medium range time frame (3 months) with story level capability and capability commitment. Waves, or milestones, are intermediate points, usually from one month to three months apart. Waves can have both a product management and a technical function. From a product management perspective, they provide a chance to review progress and make adjustments.
  • Work Breakdown Structure WBS

Below some additional definitions

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Norm Kerth's Prime Directive (should be used in review and retrospective)
  • Story Points versus Ideal Days - and Elapsed Days -
  • Crystal Clear requires
    • the following properties:
      • Frequent delivery of usable code to users
      • Reflective improvement
      • Osmotic communication preferably by being co-located
    • Crystal Clear additionally includes these optional properties:
      • Personal safety
      • Focus
      • Easy access to expert users
      • Automated tests, configuration management, and frequent integration
  • Agile Coach Failure Modes: Spy, Seagull, Opinionated, Admin, Hub, Butterfly, Expert
  • Root-causing a defect or testing the feasibility of an algorithm or a third party solution is an example of a spike
  • Measure: ascertain the size, amount, or degree of (something) by using an instrument or device marked in standard units or by comparing it with an object of known size
  • Dysfunctional teams pyramid: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, inattention to results
  • According to DeMarco, Fragmented knowledge workers may look busy but a lot of their business is just thrashing. The minimum cost penalty is 15%
  • The declaration milestone is a verbal notice from one person to another, or to multiple people, that a milestone was reached.
  • The three coach styles are Teaching, Coaching, and Advising.
  • Quantity of function is, scope, measured in terms of user stories, use cases, requirements, or features (depending on a particular situation). In software, these may be measured ultimately as objects, modules, classes, or lines of code.

Questions

  • Which of the following correctly defines the team members themselves managing assignment of the day-to-day tasks required to deliver stories at the end of each iteration? Workload Management
  • Which of the following technique can be used to apply to bring down the Lost Opportunity Cost within your team? Team Collocation
  • When should the Product Owner provide feedback on the work results? Just in time reviews
  • Who is the most appropriate person to monitor all the risks in an Agile product? The product manager
  • Which of the following is false about Velocity? Velocity cannot correct Estimation errors
  • Which of the following is NOT the skill for Agile coaches for facilitating change? Reaching agreement
  • Which tool combines the estimation techniques of expert opinion, disaggregation and analogy? Planning poker combines expert opinion, analogy, and disaggregation into an enjoyable approach to estimating that results in quick but reliable estimates.
  • Which of the following metrics can be BEST standardized across teams? Business case realization -The PMO can help the teams to enable timely decision making by standardizing the metrics.-
  • Which is the communication technique where you repeat back a summary of what the other person just said to you to confirm understanding? Reflective Listening is a communication technique where you repeat back a summary of what the other person just said to you to confirm understanding. Another benefit in this situation is that having the person hear their own ideas in another person’s voice/words may make it easier for them to be objective.
  • Adaptation depends upon understanding a wide range of information, including an assessment of the product’s progress, technical risks, the requirements evolution, and ongoing competitive market analysis. Which are the areas where every team needs to constantly evaluate and make appropriate adaptations ? Product Value, Product quality, Product status, Team performance -Every team needs to constantly evaluate and make appropriate adaptations in the following four areas - Product Value, Product quality, Product status, Team performance-
  • A standard for measuring or evaluating something. Metric - A metric is a standard for measuring or evaluating something.-
  • What BEST describes the characteristics of a Learner at Level 3 or in the Fluent stage of learning? Learners in the Fluent stage are experts -The Stage 3 Learner is at the stage of mastery. He is able to figure out the end effect of any procedure and to make his way to that end.-
  • Scrum uses the sashimi technique to require that every slice of functionality created by the developers be complete. All the requirements gathering and analysis, design work, coding, testing, and documentation that constitute a complete product are required to be completed in every Sprint and demonstrated in the Sprint increment of functionality. Sprints are kept short enough that the stakeholders don’t lose interest in the product before the Sprints are completed. And stakeholders can see that they have an opportunity to redirect the product at the start of every Sprint to optimize the value they derive from the product. At the end of every Sprint, stakeholders see new functionality. Models, requirements, and internal artefacts might be of use to the developers, but they are never shown to the stakeholders.
  • Feature X has a value of 12 and the total value of all features is 35. If the feature is estimated to cost 56%, what is the priority of this feature using relative weighting? Correct Answer is B. The priority of the feature is determined by dividing the relative value by the cost %. Hence the answer = (12/35)/(0.56) = 0.61.
  • The 100-Point Method was originally developed by Dean Leffingwell and Don Widrig for use cases and is used for prioritization as well. It is a voting scheme where each stakeholder is given 100 points that he or she can use for voting in favour of the most important requirements. How they distribute the 100 points is up to them: 20 here, 10 there or even all 100 on a single requirement if that is their sole priority.
  • When a team member approaches the Coach with a complaint about another team member, what conflict resolution technique should the Coach use? Three-step intervention path Every team needs to constantly evaluate and make appropriate adaptations in the following four areas: Product value, Product quality, Team performance, Project status.
  • Normative methodologies are based on solutions or sequences of steps known to work for the discipline. Electrical and other building codes in house wiring are examples. In software development, one would include state diagram verification in this category.
  • Iterative development means that we build a partial version of a product and then expand that version through successive short time periods of development followed by reviews and adaptations. Feature-based delivery means that the engineering team builds features of the final product or, particularly with industrial products. At least a close representation of the final product (such as a simulation model). Iterations are constrained to produce a result within a certain period of time—a time box (as short as 1–4 weeks for software). Time boxes force closure; they force us to make something concrete, often before we are quite ready. Incremental development means that we build these products such that they could be deployed at the end of one or more of the iterations.
  • Forecasting the financial value of a theme is the responsibility of the product owner, but it is a responsibility shared with all other team members—programmers, testers, analysts, product managers, and so on.
  • Decision Framing focuses majorly on, Decision framing focuses on who gets involved in the decision process. Managers who make decisions without input from subordinates and peers make poor decisions. Engineers who make decisions without input from managers and peers make poor decisions. Who makes the decision is less important than getting the right people involved in the decision process.
  • Which of the following charts shows the total number of story points completed through the end of each iteration? Cumulative story point burn-down chart
  • During a critical problem solving, you can ask probing questions, use active and reflective listening, Lead to an answer but one should avoid injecting their own ideas.

I wish you success for your certification.

Why I use a MacBookPro and OS X

Why I use a MacBookPro and OS X

2016 03 01 head

As a young developer I loved Linux, compiled new kernels during evening sessions. I struggled days to have the correct drivers for the graphic card and communication components of my notebook.

I grew older and decided to enjoy my evenings and weekends wit my family and friends. Surely I would prefer to have no virus, trojan and other evils on my workstation. So I went to macOS and Apple notebooks without regrets.

Gains

The major gains upon migrating to OS X are

  • No virus scanners are necessary, the speed-up during complex programming and development activities is tremendous,
  • No trouble when updating the operating system, updates are automatic and often no new start is required,
  • Unix Command Line and Tools are available in the console. Homebrew or MacPorts projects provide all known and less-known utilities and programs available under Linux,
  • Long lived notebook is still working and looking nice after five years of daily usage. The performance is more than adequate for software development with Java 8/9/10/11 stack and C++.

The last notebooks I had all lasted between six and nine years. The first five years these computers were used daily.

Daily Development

The tools I really enjoy and use on a daily basis for software development - mainly Java - are

  • IntelliJ IDEA IDE,
  • Atlassian Cloud applications - BitBucket, HipChat, CI pipeline -,
  • Homebrew as package manager for utilities,
  • Docker as container manager,
  • VirtualBox when I need a full-fledged virtual machine.

Daily Work

I use these tools to perform administrative work are

  • LibreOffice,
  • Google Business for team work in the cloud using collaborative tools,
  • Apple Mail Client with GPG plugin for PGP and S/MIME secure email,
  • A local Swiss article Banana for accounting and VAT reports for the federal government. I bought it as soon as the company stopped requesting higher prices for OS X than for the other platforms.

LibreOffice completely replaced Microsoft Office suite. I stopped using OpenOffice after the strange behavior of Oracle with the application.

I never really regretted leaving Linux or Ubuntu behind me.

Agile Trends Switzerland 2013

2016 10 01 head

What are the main hurdles to introduce agile approaches in Swiss companies

  • Introducing agile company-wide is a cultural change process. Such a change takes time and sometimes hurts,
  • Without commitment of senior management, the initiative will fail,
  • Doubt that lean or agile works for big projects, doubt you can convince your collaborators and middle management, doubt your customers agree with lean,
  • At the end what matters is collaborator purpose, customer satisfaction, business value.

SwissQ has published a "SwissQ Agile Trends & Benchmarks Switzerland 2013". The study can be downloaded as PDF from their website. See Agile Trends Switzerland 2012.

Below some of the findings of the study.

Major Hurdles When Introducing Agile Approaches

The number left is the value for 2013, the number in parentheses is the value found in the study for year 2012. Bold items are new in the 2013 study and have no 2012 values.

  • 72% (95%): Capabilities to handle organizational changes and the culture
  • 53% (-%): Difficulty how to handle the lost of control - from management perspective -
  • 28% (37%): Availability of skilled collaborators in the area of agile approaches
  • 25% (34%): Projects are too big or too complex
  • 23% (39%): Overall resistance against changes
  • 21% (-%): Scalability
  • 21% (28%): Missing support of senior management
  • 14% (25%): Company wide introduction of agile methods, doubts agile approaches scale
  • 14% (31%): Resistance for the internal or external customer
  • 11% (23%): No resources or time for sustainable changes
  • 4% ( 9%): Costs reasons

The trend is a clear move toward agile approaches. Companies seem less reluctant to introduce agile approaches. Major opponents such as senior managers or internal and external customers more and more acknowledge the success of agile approaches. The two first identified hurdles still reflect the difficulty of changes at company level. They are also the main reasons why Scrum introduction fails in Swiss companies for my experience. Too often companies revert to some Waterfall/Hermes process or worst to a so-called internal ad-hoc method.

We wrote in previous blogs that introducing Scrum in the development department or in the whole company is a change process. The coaches should be trained in change management and have experiences with resistance to changes.

The Scrum Master is of tremendous importance. You need a skilled and enthusiastic Scrum Master; avoid Scrum Administrator. Ken and Jeff have a clear idea who is in charge of this.

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

The Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He indeed needs senior management support, but the Scrum Master daily job is to spread Scrum in the company.

Swiss IT CIO Agenda 2013

Computerworld Switzerland has published an article about the main reasons why projects are late or cancelled in Switzerland in the April 2013 CIO Agenda edition. The study uses data from Computerworld and Experteer. As an excerpt I gave you the four major identified failure reasons.

  1. Changes during the product (62% Computer, 48% Experteer) Agile and Scrum welcomes changes in the product. It is one of the four mantra of the Agile Manifesto. All agile processes are optimised to support changes.
  2. Unclear product definition form the business stakeholders (50% Computer, 43% Experteer) Scrum requests a clearly stated vision, roadmap and story map of the product. The Scrum board is a radiator to communicate the product vision, goals, and motivations to all interested parties.
  3. Insufficient product management and controlling (40% Computer, 4847 Experteer) Scrum team, product owner, and Scrum master have clear responsibilities for product management. At the end of each sprint we have an objective and explicit control point.
  4. Insufficient communication between involved persons (36% Computer, 45% Experteer) Scrum framework enforces clear, transparent and regular communication within the team and with all stakeholders.

In one sentence, be agile, use Scrum and eXtreme Programming and the major four above problems are handled in a professional and consistent way.

Agile Trends Switzerland 2012

2016 09 01 head

What are the main hurdles to introduce agile approaches in Swiss companies.

  • Introducing agile company-wide is a cultural change process. Such a change takes time and sometimes hurts,
  • Without commitment of senior management, the initiative will fail,
  • Doubt that lean or agile works, doubt you can find agile experts, doubt that your projects can be realised with agile approaches,
  • At the end what matters is collaborator purpose, customer satisfaction, business value.

SwissQ has published a "SwissQ Agile Trends & Benchmarks Switzerland 2012". The study can be downloaded as PDF from their website.

Below some findings of the study.

Major Hurdles When Introducing Agile Approaches

  • 95%: Capabilities to handle organizational changes and the culture
  • 39%: Overall resistance against changes
  • 37%: Availability of skilled collaborators in the area of agile approaches
  • 34%: Projects are too big or too complex
  • 31%: Resistance for the internal or external customer
  • 28%: Missing support of senior management
  • 25%: Doubts that agile approaches do scale
  • 23%: No resources or time for sustainable changes
  • 9%: Costs reasons

We wrote on blogs that introducing Scrum in the development department or in the whole company is a change process. The coaches should be trained in change management and have experiences with resistance to changes.

The above points in italics are all related to change processes. You can handle two thirds of the hurdles with adequate change management training and a clear change product definition. Do not try to introduce Scrum at company level without such an approach.

Main Reasons Why Agile Projects are Cancelled

  • 52%: Missing experience with agile approaches
  • 45%: Company culture clash with agile principles
  • 41%: External pressure to use traditional approaches (Agile 51%, Waterfall 40%, Iterative 22%, RUP 16%, and HERMES 12%)
  • The used agile approaches are:
    • Scrum 84.5%,
    • Kanban 16.9%,
    • Own Approach 15.5%,
    • XP 14.1%,
    • Agile Unified Process 11.3%,
    • Others 9.9%,
    • SCRUMBAN 8.5%,
    • Feature Driven Development FDD 0%
  • 38%: Missing support from senior management
  • 37%: Missing or insufficient training and coaching
  • 35%: Missing communication between departments
  • 23%: Team does not want to learn new approach

We wrote in previous Scrum master is a full time job that the Scrum Master is of tremendous importance. You need a skilled and enthusiastic Scrum Master; avoid Scrum Administrator. The new version of the Scrum guide clearly stated who is responsible for the introduction of the Scrum approach in the company? Often people state that the management should spread Scrum in the company. Ken and Jeff have a clear idea who is in charge of this.

The Scrum Master serves the organization in several ways, including:

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

So the Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He needs indeed senior management support but the Scrum Master daily job is to spread Scrum in the company.

Do Agile Methods - Scrum - Motivate your Team?

Do Agile Methods - Scrum - Motivate your Team?

2016 02 01 head

Well my current experience is that the answer is a sounding YES.

Developers love to develop software using Scrum. The motivation and positive energy just explodes. People talk together, build as a team better products and enjoy the daily activities.

Stakeholders and in particular customers or users embraces the advantages they get.

A whisper can still be heard:

Yes, it is not without consequences for the organization.

Say your team is developing software products with Scrum. We have the following roles:

  • the stakeholders
  • the developers (Development Team)
  • the Scrum master (SM)
  • the product owner (PO)

The Scrum Team is the composition of the development team, Scrum master, and the product owner.

Stakeholders

Stakeholders love Scrum. Every two weeks they have a new application version they can use, test, and get feedback from all users. This is the dream of every key account manager.

Because a new release is available every two weeks the stakeholders should also provide feedback every two weeks. They sometimes hate the pressure of agile and Scrum.

Developers Team

Agile methods - Scrum, XP - are fun for all developers. Suddenly everyone can see your code, so at the beginning you as a developer must cope with different views how good code should be written. Suddenly you must master Test Driven Development TDD, mocking, unit test, legible documents. But, once you have it, you start to experience the "flow" and enjoy the atmosphere and to deliver at the end of each sprint a new software.

Later you realize that Scrum says the team is responsible. You must acknowledge that the product success is also your success. Each design decision is now also driven by ROI considerations. If you master these responsibilities you suddenly discover the world of engineering. It is creating great products with an optimal balance of external quality and costs without ever jeopardizing the quality of the core. You can never again deny that you as developer are in charge.

Scrum Master

Scrum master is cool with a team enjoying Scrum and the flow of success. You just have to realize you are not a master but the enabler of a team of talented engineer.

So you need to discover your "the lonely cowboy riding in the sun" song why this job is so rewarding.

Product Owner

As a product owner you control the budget of the product, the priorities and at the end of each iteration you can change all priorities and goals. Cool isn’t it. But wait as a product owner I am responsible for the budget and product success and each time a member of the team asks me something I must have an answer ready.

Scrum is cool and we enjoy it. And Scrum makes everything transparent and fast. Every two weeks a new version is delivered. This version must be evaluated, accepted or a list of improvements must be provided in the next days. This rhythm is fast, really fast. Once you are up to this speed you will enjoy the flow.

Cautious Words

Middle management often struggles with the agile approach at the beginning. See for example the discussion about manager role in an agile environment in the LeSS approach. Be assured the results are worth the effort.

Reading experience report or digging in the findings of Kotter you realize success or failure goes through how you handle middle management.

Minimizing Undone Work when Working with Regulatory Departments

Minimizing Undone Work when Working with Regulatory Departments

2016 01 01 head

The Scrum and agile mantra is to have a "ready to ship" product each time a sprint is completed. You must avoid any incomplete activities at any price.

Incomplete activities are also called Undone Work; they are technical debts in your software, hindering its delivery to customers.

Regulatory and traditional quality insurance departments requests all kinds of documents such as review, test results, risk analysis matrix. They want insurance that their view of quality is fulfilled.

Scrum sees quality similar to the lean production approach. Quality is build into the product and you do not need any documents proving you have fulfilled this goal. Your sole goal is to optimize the process to produce the best products, not to repair them after production.

It is the sole responsibility of the Scrum team to guaranty quality. But Scrum teams also learnt you cannot win against big corporations. So you have to define solutions satisfying the QA departments with minimal overhead and almost no undone work. We have experience working with quality insurance and TUV or FDA driven regulatory departments. We use the following approaches to handle the needs of the regulatory departments, seen as stakeholders in the Scrum terminology.

  • Use static analysis tools such as PMD, Checkstyle, Findbugs to create quality gate reports for your QA department. Thousands of checks and hundreds of pages of reports will satisfy any QA department. Plugins exist for Eclipse and continuous integration servers.
  • Use review plugin such as Eclipse Jupiter to create these still mandatory review reports on the source code. These reports are useless in an agile team working with techniques such as refactoring and pair programming. But they are still mandatory for the majority of traditional QA departments. The plugin allows you the generate nice looking reports and to implement the findings at the same time.
  • Use Test Driven Development approach and create a lot of unit tests. By slightly extending the logging features of JUnit and by using code coverage tools you can create reports showing which source code was tested. Add some annotations to your test cases, and you have full traceability to your stories and associated software requirements. With a small amount of work you can generate thousands of pages of information and provide the PDF documents to the regulatory department. These documents are also TUV and FDA compliant.
  • Use Behavior Driven Development approach and create acceptance criteria for all your stories. Using the reporting features of easyb you can create acceptance test reports for all your stories. It generates hundreds of pages of information and provide the PDF documents to the regulatory department. These documents are also TUV and FDA compliant
  • Use continuous integration servers to run all the above measures and generate the documentation at the end of each sprint or release.
  • Link you version control system with your continuous server, issue tracking system and unit tests. So you can generate release notes stating the list of closed issues with the associated source code and unit tests verifying the correctness of the change.

Similar tools are available in the .NET and C++ community. T You can easily satisfy your QA and regulatory stakeholders with a lot of reports nobody will ever read. A real Scrum team corrects weaknesses during the development process and always deliver a software of the highest quality. The reports can only show the inherent quality of the software and are not worth the paper they are printed on. But you satisfy powerful stakeholder groups and can more freely work on the most important goal. Deliver on time and in budget the best software the customer wants to have.