Agile development emphasizes effective communication and learning through continuous feedback. Backlogs are tools to manage the discussion about the features of an evolving product. They are simple in form but demanding in content. Here are a few challenges.

1. Too detailed

By writing detailed development blue prints like traditional requirements specification, the product owner wastes time and takes up space from the creativity of the development team. The things in the backlog are comparable to the product breakdowns presented in traditional project plans. They are intentionally incomplete.

For example, a software developer will probably know what kind of program logic is needed to implement the return, OK, add, change, and delete buttons in the interface. In this case, no separate user stories are needed to describe them in the backlog.

2. Too big, projected too much

A Backlog with several hundred or even thousands of items predicts the work of the development team for years to come. It is premature to include things that are not timely in the backlog. It is not even certain that they will ever be done.

3. Business benefit, metrics missing

In order to prioritize the backlog, it is important to understand why the product has these very features. Cost-benefit calculations must be possible at least at a rough level. For example, a user story: As a marketing representative, I want our website to use cookies so that we can target our sales and marketing efforts well to our customers. From this, we can continue the debate about whether the use of cookies is good business.

4. The “why” of the user story is wrong

For example, the user story: “As a customer, I want to use Digital Service X to save nature” probably describes the need less than “As a business owner, I want our customers to use Digital Service X to save 10% on our costs. Adding metrics often reveals whether we are doing the things that are actually required for a product to succeed.

5. Not Concrete, too abstract

The need for business alone is rarely enough. The development team wants to know what they need to produce. For example, what should the development team do to implement the user story “As a company owner, I want a strategy to secure growth in shareholder value in the years to come”?

6. Full page user story

The user story format is not suitable for all situations. Its use is not mandatory. For example, complex software logic or visual appearance is difficult to describe in a single sentence. The backlog can be augmented with various diagrams, sketches and calculation rules.

7. Architecture is missing

The structure of the backlog describes not only the work in progress but also the architecture of the product. In a good architecture and backlog, components (especially themes and epics) can be built, published, and replaced independently. A spaghetti code is easily generated from a ticket list.

8. No increments are generated

A traditional requirements specification often describes a large number of components that are integrated together just at the end. An incremental and iterative model of agile way of working where we have a constantly functioning and evolving product requires a backlog that supports that. For example, since the user interface and the backend are not built separately, they are also not separated into their own items in the backlog.

9. No discussion with team and users

Because the backlog is intentionally incomplete, the product owner, users and developers should actively discuss with each other. Understanding of the product is not conveyed through the sending of documents and emails but through the interaction between individuals.

10. No feedback: POC, alpha, beta, MVP

When writing a backlog, keep in mind that the product develops piece by piece. The product is made available to users and customers for evaluation at the earliest possible stage. It is better to fail with a proof-of-concept than at the end of an expensive R&D pipeline. The backlog tells whether the feature will be published in POC, alpha, beta, or later.

11. No changes, no reviews

The backlog describes the part of the product currently under construction. It differs from the project plan in that it is not frozen at the start of the project. Instead, the product is intentionally improved through customer and user feedback. The review is an event where the Scrum Team discusses the future of the product with stakeholders.

12. General definitions for the definition of done

General specifications such as non-functional requirements, security policy, and user interface standards are described in the definition of done. In this case, they are not repeated unnecessarily in the backlog.

13. The division of labor into teams is not communicated

The structures of the development organization, product, and backlog tend to match each other so that dependencies can be managed within each team. Strong planning in advance or large inter-team meetings have not proven to be a fast enough and interactive way to communicate.

14. Platform specific teams

It is difficult for a product owner to optimize the value of a development organization’s work if it consists of knowledge islands. In the backlog, platforms such as Android, iOS, and Windows are only considered at the sub-level, which belongs to one team.

15. Double work, missing parts

The backlog, open to everyone, spreads the overall picture of the product so that each feature is built exactly once. In terms of component reuse, the agile world is opportunistic.

Traditions and organization of work are the root causes of the above. The consequences unfold when you take into account the emergence of understanding and the changing needs as development work progresses.

Keynotes of Niels Pflaefing “Organize for Complexity” and Brain Robertson “Holacracy: A Radical New Approach to Management” summarized the agile position on leadership.

In a rapidly moving world old paradigms of management are not fast enough. Teams near the customer must do the decisions using the power that organization’s constitution assures them.

More information about their ideas can be easily found from their books: Organize for Complexity and Holacracy .  These ideas of leadership are essential in understanding why agile transformations are so difficult. It is hard to be agile if the management structures are not changed.

Another hot topic was scaling. SAFe is not the only option and LeSS seems to get more support from the agile community than it, because SAFe’s top down approach is less capable of  changes.

Scrum Alliance has now more than 400 000 members and it is growing with about 6 500 new members every month. The number of trainers and coaches is now 188. Members will get more content in Scrum Alliance’s site and trough the learning consortium.

Scrum Global Gathering 22.9- 24.9.2014 in Berlin was sold out. Its 600 participants heard the good news:

1) The number of certified members of Scrum Alliance of  is now 350 000 and it will grow by 5 000 every month.

2) Certifications will be extended so that the number of the upper level of Certified Scrum Professional certificates will be determinately increased with the help of additional training courses.The 200 trainers and training companies  involved in the community will increase the range of advanced training courses in the  technical and the leadership areas.

3) Scrum is converging as the organizations in the area, Scrum Alliance and Scrum.org (8 000 members), agreed on a common definition of Scrum.This means in practice that our offerings of current and forthcoming trainings at agile leadership, interpersonal skills, facilitation, agility, scaling, Lean, Kanban, Certified Scrum Developer, agile testing, agile architecture, etc, etc will get increasing global marketing support from Scrum Alliance.Course development takes place in the spirit of the Lean Startup based on customers’ needs.

We are able to offer advanced courses that our clients request as the course contents have already been prepared at the global level. Many of the MIF‘s interaction skills courses and others courses are inherent add-ons to basics of Scrum.

I found a revealing discussion at a popular suomi24.fi-site titled Ketterä IT-helvetti (agile IT hell ). It is amazing how often daily Scrum is practiced just opposite of Scrum’s basic idea of a self-organizing team.

This 15 minutes is just for the developers to say hello to each other and coordinate days activities. They need to know the situation after yesterday’s work because software development is not predictable. Sometimes tasks estimated to take 2 days take 5 days and sometimes they are ready after one day. So everyone needs to know where the team is and agree on what to do next.

The metaphor of chickens and pigs is meant to make sure that managers do not use that for micromanaging the people. Command and control is bad because it destroys peoples’ natural work motivation. People including developers want to achieve something and autonomy to do it – not that they are given orders and controlled tightly. Command and control reduces productivity and creativity which is really harmful in an art like software development. Psychological studies have shown that time after another.

Pair programming can be done in a way that does not decrease the motivation. As the code is owned by team and every team member is responsible of changing any peace of it the team needs a way to teach the secrets of the code modules to everyone in the team. That is pair programming. It prevents harmful specialization and at the same time decreases the number of errors in the code. Your pair is not watching and controlling what you are programming but you two work together to create great software. Two creative minds coding and discussing together is a way to learn from each other and do a great work. Pairs are changed normally on daily basis so that different angles on the problem can be thought. Pair programming should not be a stressful situation like the one described in suomi24. The team should discuss about the situation in its retrospective and decide how to continue to find the the joy of work that agility gives when it is practiced at its best.

Agile software development has often seen as an foreign element leading to chaos in Virginia Satir’s model. Current situation of Scrum is indeed somehow chaotic. Key persons are arguing against each other and it has been very demanding to define what Scrum actually is? Ken Schwaber’s ScrumGuide is our current definition but it is not ready for a Scrum Alliance’s multi-choice exam.

There are many different versions or variations of Scrum which may or may not be under a common framework. Common thing in these is that they are more realistic and less extreme. It has been visible for a while that radical extreme Scrum has given space to real life. Some of these modifications clearly belong under the title “Scrum but” but some others are coming from Schwaber and Sutherland, who are the authorities who define Scrum.

In the London Gathering Schwaber introduced product backlog refactoring meetings where team collaborates with the product owner to create actionable product backlog items. In Munich Gathering Sutherland emphasized that the user story must be ready for the Sprint, which means that a good enough specification exists to continue.

The main difference here between Rational Unified Process and Scrum is in the collaboration between the developers and the product owner. In RUP there are strong roles and artifacts that are just handed to next group of people. Product owners’ role has got more content by the discussion of release planning – still obscurely defined time-box of Scrum.We are now also openly talking about undone features and telling that team might not be able to complete a user story to the point that it can released. So we add a stabilization Sprint where undone features are completed before the release.

Situational leadership model was my favorite in the 80’s. In addition to Tucman’s model it was also well visible in the Munich Gathering. Actually that means that we have to admit that leaders can’t just assume that teams self-organize when they are just empowered to do so. Sometimes directive forms of leadership are needed though we understand the drawbacks of command and control.

Schwaber’s integration teams that he introduced in his book Enterprise and Scrum have not been heard much in talks of the Scrum people. The case studies of real life projects tell clearly that defined organizations are used, not just self-organizing flocks of business and technical people. The question of scaling agility is interesting and clearly not solved in a way that theoreticians and practitioners can both accept. Actually, I would like to asses (or rather measure) different agile solutions instead of arguing about right or wrong Scrum.

I am taking part to Scrum gathering this week. This is fully booked though the economy is down. The talks that I have heard so far are encouraging and enjoyable. I am here to see friends and to hear their stories and experiences. There are many issues that I should rise (in this blog and otherwise) but I the thing near my heart is collaborative design. Developers are still struggling with functional organizations. Product owners don’t talk with the developers and we have subgroups of developers who communicate only with specifications. This might be because of the early phase of the agile adoption but understanding the cross-functional teams might be difficult too.