From semi-finished to finished user stories

One of the cornerstones of being agile is to deliver done features by the end of short sprints. Done as in potentially shippable. Done as in implemented, tested, documented and possible to deploy into production.

 

This is a typical semi-finished user story

Common arguments why user stories are left semi-finished:

 

 

 

• we are not used to copmleting them (...yet)
• we think it is unfair not to take credit for partly done work (it looks worse than it is, and we are afraid that management does not see this bigger picture)
• we do not see the point in delivering smaller parts that is truly done
• I think I am more effective if I can focus (all my time) on the one type of task that I am best at (rather than optimizing for the team and product delivery)
• we are different than other product development teams –this might be a good idea in other teams or organizations, but not here
• we are not prepared for the visibility this will provide (goes for both management and team members)

Ripple effects of done

Why is it so important to deliver finished user stories?

Focus on delivering something that is finished each sprints will provide you great benefits:

1: Deliver real value -early. Get the great features out to the customer, not storing them on the shelf.

2: True visibility of progress, and make any unresolved issues visible. Handling unresolved issues before moving on to new stories will reduce risk for the company/product delivery, and create visibility of the reality. This is important for any team :)

3: Ability to deliver the true minimal viable product. Help each individual on the team to participate in dividing the user stories into small enough pieces. This in turn will help the company to deliver the true minimal viable product, making the product development more flexible: you will be able to deliver a first release, then learn, then add more features, learn more and so on. –A great place to be!

4: Pull together as a team. The team will become great at collaborating to finish a user story and helping each other out on that rather than only optimize for the individual preferences of tasks to solve. This can seam harsh in theory, but in reality, the reward is intrinsic motivation triggered by being a part of something greater than the, it gives a sense of purpose. (of course the teams needs to be put together with interesting tasks for everyone most of the time, and by people that are motivated by and skilled at similar and different tasks) 

5: Trust. When you deliver finished stuff, the rest of the organisation trusts you. Then you get the freedom to make smart choices work a way that make sense. 

 

How to get there?

In Scrum you do get some help on visibility of how good you are on finish user stories:

• You do not review any partly done user stories (show only finished stuff)
• You do not take credit in any sense of user stories that are partly done (it can be visualized on a burn down chart)

Does it seem harsh? Maybe. Still I think the reasoning behind focus on completing user stories makes it worth while, I can not see how anyone can be agile and still leave unfinished work. 

• Understand the reasoning behind by reading up on the topic, talk to others and join the agile community. Then you need to work the knowledge into your culture. Inspire, educate and engage. 

• I reccomend any team to give it a whole harted try for 6 months

•  I would also allow time to make the necessary adjustments:  

 Most certainly, there are many reasons both technically and human that needs to be addressed in order to get to a place of making user stories that is done and truly done.

You can do it!

Further reading:

• This is a great read! http://www.mountaingoatsoftware.com/blog/dont-take-partial-credit-for-semi-finished-stories
  
  
• Read this if you are interested in the details on velocity:
  http://www.agilelearninglabs.com/2013/08/story-point-accounting-across-sprints/
  
  This is related, about pulling together as a team to complete stories:
• https://www.ibm.com/developerworks/community/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/are_you_struggling_to_complete_user_stories_each_iteration1?lang=en

Want to work agile? Deliver on time!

How often does this train leave the station? It is obvious that it is too seldom. I think this is the best picture to show how feature creep looks like. We have all seen it in software development:

The less frequent the train leaves, the more important it becomes to get on it! All features "needs" to get on the train, because they are so few and far between.



And this train will be delayed. That is for sure!
It becomes a negative self-fulfilment: the releases are happening too seldom, and consequently we need to pack them with features. The result is delayed releases, and because of this there will be even longer to the next release, and therefore it becomes even more important to get all on-board before the train leaves the station.


This is the tram close to where I live. It leaves every 7th minute. It started departing with this frequency last year (down from 15 minutes), and it resulted in several changes:

1) I do not look at the time before I leave my house: I am ready when I am, and there is no need to rush or worry that I wait too long

2) The driver does not wait for passengers that are too late and who is running the last 50 meters to make it. The driver just closes the doors and drive away on the scheduled time.


How do we get to this beautiful state when delivering software?

1: Create awareness, acknowledge the problem
I used to work in a team where the stability of our software decreased between releases. This was not a happy state. We saw that it could be rectified by increasing the release frequency.

Other good reasons for having more frequent releases could be: delivering value sooner, time to marked, need to respond to change, as a means to reduce work in progress and produce finished stuff

2: Build up the urge to change the situation
Change can be difficult, and it is hard to convince others. Therefore, I have usually worked with those that agre this is a good idea in the first place. Working with people that share the idea together identified the bare minimum to get started.

3: Just do it
It has sometimes felt like being a bit irresponsible to release without a big fat release process. It is important not to underestimate the power of habit and learned behaviour. Just make sure to have a new behaviour to replace it with, and that the team itself develops this, so all have the right ownership.

We also tried to release early to a few customers in the beginning, and I was suprised to see the enthusiasm and willingness to receive software before we "officially" had released it.

I have also fought (and won) against internal release-departments accusing us for being irresponsible. Fortunately, we flew under the radar for some time so that our practice of releasing often was well developed before the other departments attacked us.

4: Be aware that it is no free lunch
I learned this: there are lots of reasons we do have this long release cycles today. In order to get to short release cycles, those reasons need to be dealt with. And this is not so fun. Just hard work. You need to be patient and remember your goal and the pain you had with your long relase cycles. Someone in the team should have the role to keep the goal sparkling in front of the team, and remind them of the pain and gain relevant to your team's efforts.


Good Luck and good summer :)

I am looking forward to my tram is back on a normal 7 minute schedule, currently they run on reduced summer time tables, waiting for late running passengers, getting delayed, and making me stress getting on time in the morning.

Handover: "us" and "they"

In October, I got this question: “Can you help us to make our hand over process work?"

Interesting question!



Many agile-religious-people will automatically answer that there should not have been a hand over process in the first place. I think there is no such thing as "should not" in IT or in organisations in general. There are many very valid reasons why things evolve into what they are, and most organisations do have some form of hand-over at some level.  The challenge is therefore; what to do within this scope?

Interesting topic!!

This organisation have looked at what is the root cause of this situation in the first place:

• Optimisation for silos; this have ensured high quality of technical expertise, but also not optimising for the whole value chain
• The needs of the customers have been primary focus (very important!) now the focus needs to be on the longer term and market transitions as well (also important!)

 

Then the organisation looked at next steps:

• Acknowledgement of situation
• Management decision making for long term solution (including some reprioritisation)
• Communicate the target picture
• Involvement
• Firefighting: Add people with great people skills that can fix things between departments and make people talk to each other, and just make things happen
• Start working on the long term solution

Being part of this now, make me reflect on the whole "us" and "they" as a topic. And I do not think there is one single organisation completely without this challenge in one form or another. The big question is; how to deal with it?

I remember back in 2003, when I was fresh out of university with my masters degree, and got my first job. The company I worked for had recently re-organised from service-centric units to be divided into three departments: development, maintenance and operations.

We believed documentation to be the main API between the development and the maintenance parts of the organisation. To make software from development/projects work in production, the maintenance department only needed to list specific requirements to them –and perform audits.

This created an optimised environment for both projects and maintenance, however we also got some frustration based on the "us" and "them" feeling:

Frustration in the projects: somebody from the outside (the maintenance department) came in and disrupted the flow they were in. Lots of the requirements were way out of scope (not part of the contract) and presented in a not so collaborative manner

Frustration in the maintenance department: why did not the projects take into account how the systems were to work in the real life (real servers, real security, real logging, real installation files that actually work at night in the short and few hours of downtime the SLA could allow)

However, we also had some great people on board, that helped us remember that we were in the same boat:

I worked with a great project manager who repeated her mantra; “We have a shared goal here, for our customers and for our company. How can we make this work together?” This is a great take-away, and I have brought it with me and thought of it every day since. This learned us to see that we were part of the same problem and the same solution.

How to change the “us” and “they” mentality is only possible by working together. Working in different departments might work only if:

• the managers are well aligned and share the same goals.
• people from all departments are included in the project work during on a regular basis, at least weekly
• people from all departments are informed, before it is strictly necessary, and kept in the information loop.
• I do not think it is possible to over-share! invite to reviews, send out summary e-mails, drop by for coffee, have lunch together
• people from all departments are invited to parties, kick off and other events 
• do not underestimate the importance of team t-shirts :)

 

 

A great exercise is to think this through on a regular basis:

• Where in my organisation do we have "us" and "them" challenge?
• What can I do to improve the "we-are-in-the-same-boat"-spirit?

How to control everything in your project!

Guess what!? I have discovered a process that let you control not only timescale, budget and quality but also scope, risk and produced benefits!

During the initial project stage, the business side will know all these aspects and make the well-informed decision to start the project or not.


And this process is called Prince2


By now, I guess that you have realized that I am not serious.

I find it a bit strange that people buy into this illusion, that it is possible to know all these aspects up front.


On the other hand, I find too many agile practitioners being too fundamentalists in their approach to agile. We have to take into consideration that organisations do have some boundaries that they need to adhere to. Not everyone can or will go all in from day one.


I think one solution is for the Prince2 fanatics to emphasize the “management by stages” which equals “embrace uncertainty”.


I also think Agile fanatics should be less fanatic in their communication, because what is the result of fanatic communication? People that already think the same way as you; they will nod, whereas the rest will dismiss all you say.


Prince2 provides a common vocabulary that is great when communicating, and the agile community provides the values and methodology that we need to deliver (the right) software.

I think we can use both to get where we want. We just need to

• be practical about implementing Prince2
• not getting bureaucratic
• emphasize the flexibility that is built in
•  implement agile and lean into this super-thin framework   

    

After all: this is what we want:

“Speed, Quality & Low Cost are Fully Compatible
Companies that compete on the basis of speed have a big cost advantage, deliver superior quality, and are more attuned to their customers' needs.”

-Poppendieck

Have a nice weekend!

Cheers,

Eira

-Prince2 certified, agile at heart