Category Archives: Scrum
Recently Luis Goncalves published a blog post about retrospective smells. It’s a good article and worth a look and you can find it here. Although the article in general is interesting and I do agree with most of it, I do disagree about one point being an antipattern: “Line Managers want to attend”.
He quite logically deduces that although they might very well attend on good intentions, their participation can interfere with team member’s confidence in raising issues and talking freely about topics at hand. Leaving manager’s out of retros seems like a proper cure, but I get the feeling we are here treating a symptom to a way bigger underlying issue – lack of trust.
It’s quite common that team members and employees in general are careful when manager’s around, especially if they are new to the team or the company, but instead teaching people to avoid direct communication it should be fostered. It takes time and effort to build that trust, but eventually team should feel comfortable talking about real issues directly and openly with the management. Properly facilitated retrospective is the perfect place to practice and train this open and direct communication.
This trust will eventually work both ways and it’s extremely important for transparency and openness in the company culture. Still it will take time and there is no benefit in trying to force it so I would actually recommend doing retros sometimes with and sometimes without management. Depending how well it goes and start bringing the management in more and more if the trust starts to build up.
There is another benefit in having management present and namely they are more likely to support and help solve the issues if they understand “why” something should be done instead of just “what”. People can bring their whole expertise and experience to the table only if they have proper understanding of the situation and participating in retros can really help in achieving that. People (includes managers!) commit to certain tasks or plans a lot better if they take part in designing them or better yet: let them be part of the solution.
The retrospective is the place for process improvements and probably the most important improvement you could ever achieve is is fixing the communication gap between the team and the management.
Finally I’d like to point out that most of the retrospectives I have facilitated had a manager attending and it never seemed to be a problem. Maybe I’ve just been lucky, but I personally do intent to push my luck and I will keep inviting everyone to the retros.
Illustration by Martha Bárcenas
Minimum Viable Product is not a new idea and it has been around for a while now. Like any buzzword that takes of it has had it’s fair share of confusion around it and plain miss interpretations. Some people to see it as overly simplistic idea where you get started with the absolute minimum.
While it is still good idea to get the first round of feedback from colleagues, friends and family as they certainly can provide some very useful early feedback even for something as simple as a login page, but a login page is hardly a product and some way of being viable. Minimum Viable Product is not just minimum, it is VIABLE.
In short the idea is to do a simplified version of any given product and then put out out there in the market to start gathering all important real end user feedback. The product has only the key functionality implemented.
This makes sense not only because it saves time, but it may also lead to vastly better product. Simple product tends to be simple to use and majority of software features are never or hardly ever user. Analysis based on Pareto principle can be applied to software engineering and leaves us with a statement that says “20 percent of the features provide 80% of the value”. The features that are never used is widely considered as one of the greatest causes of waste in software engineering.
Not used features have been implemented making the code more complex than it needs to be. More code lines mean more bugs and harder and more time consuming maintenance. Bug fixing will be targeted to fixing bugs that affect features that users don’t need etc.
Scrum co-creator Jeff Sutherland also makes a point on this. He talks about value curves where he explains that after delivering 20% of the highest priority stories the value produced starts to decline and it’s time to re-prioritize to get a new value curve. Scrum methodology fits well into developing a minimum viable product.
The fundamental challenge with Minimum Viable Product is not just minimum. A login page is hardly a product, it still has to be VIABLE. This leaves us with the biggest challenge when it comes to Minimum Viable Products – what is viable? This can very hard to define and various greatly depending on the existing market. When creating something new when the market is in virgin state something very simple can be enough. When there are already players in the given market, something viable can be a lot more complete product.
Still we history has shown that consumer tend to value good user experience over bunch of features. Just look what happened with iPhone, when it first came out, it did not have copy / paste, no multimedia messages, no 3rd party apps and hardly anything we take for granted now.
To get started we have to make assumptions about customer demand and needs. The Minimum Viable Product helps us validate these assumptions. There various ways our assumptions can be wrong:
The customers don’t want given product
our assumption of minimum viable is too restricted and is not useful for customers
the customers would settle less than was originally thought
Only number 1 is clearly result capable of killing the business.
Harvard Business Review offers two versions of Minimum Viable Product: validating and invalidating. This post touches mostly validating minimum viable prodcut. You can read the whole article here: http://blogs.hbr.org/2013/09/building-a-minimum-viable-prod/.
Agile or Lean or Agilean? There is a lot of confusion about the relationship between these two . Some people say they are completely different, some say they overlap and some say lean startup is a fusion of the two.
If we take a look at the Lean Software development principles according to Mary Poppendieck in her book on Lean Software Development:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- Optimize the Whole.
Then we take a look at the original Agile manifesto.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over
processes and tools
Working software over
Customer collaboration over
Responding to change over
following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
There of course quite a few things that overlap it we dissect these statements.
“Eliminate Waste” is the principle of getting rid of things that don’t produce value. Retrospective is a very recommended practise where teams try to hone their process and see what is working and what isn’t. Essentially getting rid of waste.
“Build Quality In” seems to have similar qualities to “Working software”. Also Test Driven Development is a very common technical practise usually considered an “agile” practices. Also Poppendieck agrees this is essential to Lean when applied to software.
“Create Knowledge” underlies the importance of communication so that people know what they are doing and understand the problem domain the same way. This is again very essential to agile as well. The manifesto states that “customer collaboration over contract negotiation” which can be understood as a way of creating knowledge.
“Defer Commitment” has it’s relative in the agile world. Let’s take scrum for example. You only work on the items with top priority in the product backlog. You only work and talk about just enough items to fill the sprint backlog. All the rest are just titles. Product backlog item is just a promise of a further conversation.
“Respect People” is clearly similar to the first phrase of the manifesto “Individuals and interactions”. Both approaches put a lot of importance to people.
“Optimize the whole”. This might actually something where there is actual difference. Agile is very open to transparency and openness and scrum is very open to everyone attending defined practices like daily stand-up to listen or management participation is recommended for retrospectives, but still it is generally very concentrated on the development team.
Agile and Lean might not be equivalent, but they certainly have quite a lot in common when it comes to values, principles and even roots. I consider Lean to be an approach to improve effectiveness and it does have roots in manufacturing industry. Primarily Lean is about getting rid of things that are useless – in lean terms – waste. Agile on the other hand come into being when 17 experience software professionals got together and talked about giving a common name to practices they had found useful. Practises that were similar in nature: reactive, adaptive etc. A lot of those things also had roots in manufacturing industry, especially in the way Toyota worked and still works.
Saying Lean and Agile are not equivalent is one thing, saying they have nothing to do with each other is another.
Scrum is definitely the most successful agile methodology so far. Everywhere you go you can now hear the word scrum in the most absurd context. Scrum roles and titles have partly replaced more traditional titles.
Scrum becoming mainstream is not only it being superior to any other option. Today there are two major organizations offering their courses and certification services: Scrum Alliance & Scrum.org.
Kanban is not as far with certifications, but the kanban community seems to be heading that way as well. Last year the Lean-Kanban University started to hand out accredited kanban trainer -badges and more recently accredited kanban coach -badges appeared so the writing on the wall is clear.
Certifications might not be much to be proud of these days, but does not mean the classes are not any good. Still these classes are as good as the teacher and I for one got very lucky with the instructors I had in my both certified Scrum classes.
I had the privilege to attend a certified Scrum Master class by Jim Coplien and he is one of the so called gatekeepers of the official Scrum guide and he´s been around since the digital stone ages. As expected his expertise exceeds far beyond scrum and I still consider it the best crash course in agile. Later I had the chance to attend Scrum Product Owner class by Gabrielle Benefield and that also was as good as a two day class can be. Not because of Scrum, but because of the vast amount of experience she shared with us was not only enlightening, but also inspiring.
If my memory serves me correct, I attended the first official Kanban class by David Andersson in Finland. Kanban definitely has merit as a methodology, but you could still tell that the course content nor trainer was not as polished as the aforementioned Scrum counterparts. Now more and more Kanban trainers are popping up and with more trainers and organized courses the courses and their content will get better due to more experience in the kanban community.
Classes are as good as the trainers and the certificates are just a semi necessary by product. Certainly classes by different trainers have similar agendas, but the trainers definitely have more than enough room to accommodate attendee requests and add their own spice to it.
Still certificates themselves should not be considered essential. After all you can get a bunch of certificates even from w3schools.com. The bottom line is that although the certificate might not be much to brag about, these well established classes can still provide a lot of value.
Sometime ago when I had stomage ache I decided that I wouldn’t want to suffer any longer than necessary. This was a clearly an issue that needed to be handled in timely manner. I decided that I would skip going to a generalist doctor and went straight to surgeon armed with a black marker.
Me: Hi there, I need you to appendix, it’s done for.
Doc: … what?
Me: Look, let me show you. Grab a scalpel and start here around waistline and follow this dotted line for few inches. Then reach for your clamp and get hold of the appendix and then just cut it off with the scalpel.
Me: Look I downloaded some pictures from the internet, this is what the appendix looks like and this is a picture of how it looks after you take it off and here you see what the stitches look like after you finished the job.
Doc: … but…
Me: Oh, almost forgot, don’t bother with anestesia as I´m on a budget here and I´m pretty touch and I can take it without.
Doc: … aaaa… ahem…
Me: So here’s the specs as user stories and the all important time estimates
- As doctor take out scalpel and make the cut (1min, 30 sec)
- As doctor spread the cut (30 sec)
- As doctor use clams to get hold of the appendix and Then cut it out (2 minutes)
- As doctor use the needle the sew the stitches (4 minutes)
Me: I´ll even allow you some 15 minutes for setup time and 5 minutes afterwards the wash your hands. I assume surgeons get paid around 100$ and this takes less than a half an hour so let´s just round it out so I shall pay you 50$ for the operation and of course you are liable if anything goes wrong.
… And this is when the guys in white jackets walked in and escorted me to a comfortable room with padded walls.
The problem is (more like one of the problems) is that product owner is supposed to have a vision about the product and clients rarely have even a remotely good idea what the underlying problem was. They may very well not even know the solution, all they know are few symptoms.
ps. Pics courtesy of wikipedia
If there is one thing that embodies agile mindset then it’s the continuous and constant apply, inspect and adapt -cycle that goes on and on. In mature and advanced teams this is a natural part of daily work and goes on even without extra rituals. Still there is time and place to do it formally and that is something we call a retrospective.
Since people learned to communicate people have gathered around a camp fire to share stories and tips around what worked and giving evolution a boost in the process. Retrospectives are a modern day way to achieve the same thing – learn from experience. Retrospective offers a chance for a structured inspect and adapt session. I roughly divide retrospectives to 3 categories: sprint, half year (some people call these iteration or release retros) and full project retrospective. All these have different meaning and more importantly a different scope. Sprint retrospectives are the corner stone of process improvement on daily activities. It’s one of the key artifacts in Scrum and implicitly defined in scrum guide. To do proper scrum, you have to have a retrospective at the end of each sprint. Kanban does not define retrospectives, but it’s highly recommended to do them every few weeks. Still in a sprint retrospective you can only do so much. If you only look back few weeks, you can only touch the surface. If you want to dig deeper, you need to look way back and dedicate time for it. That’s when a half year or a project retrospective comes into play. These take a lot more time and planning to do them properly. To look back a half year, you need at least 4 hours even with a small team, preferably a full day. Time needed is directly related to time frame you are looking to reflect on and how many people will attend. If you have more people, there will be more conversation and you need more time to make sure that everyone gets to speak their mind.
When done properly, retrospective empowers the team. It makes them feel like a change is a possibility, it makes them feel capable of change. Might sound like an obvious thing, but for a young guy at a new company these things are NOT obvious. Reasonable tasks that make a difference empower the team. This is also a key ingredient of creating self organizing teams. Retrospective is a tool for satisfaction and improving customer collaboration. You often run into prejudice that having clients present will hinder conversation when the contrary is true. Having another perspective only fuels conversation and diversity helps when creating action plans for the future.
“The most important thing about retrospectives is that you have them”
-Henrik Kniberg, Crisp
I could not agree more with Henrik, as long as you do retrospectives, you have hope. Format matters, but start easy and do what ever feels comfortable. Just going off site for a coffee and a donut might good way to start. Just grab a notebook and pen and take notes during the conversation. This kind of structureless retrospective can work for a short while, but you might soon run into problems. Retrospectives that don’t result into doable actions are not really worth that much in the long run. Using 5 phase retrospective structure that Diana Larsen & Esther Derby introduced in their book is highly recommended. Each phase has an explicit purpose and should not be skipped, how decide to facilitate each phase is up to you and open for variation. Just for a quick introduction or reminder what the phases are:
1. Set the stage
Create focus on the matter, agree on rules and make sure everyone understand what is the purpose of the retrospective.
2. Gather Information
Create common understanding what has happened during the project or time span you are reflecting on.
3. Generate Insight
Spot patterns and underlining themes on information gathered in previous phase.
4. Decide What To Do
The most critical phase in the retrospective so really put effort here. What you need is clearly specified doable tasks. It seems to help if you tell people to handle it like sprint planning where you take big backlog items and split them to tasks. Retrospective tasks should be something that you can write on a card and put on the team’s task board.
Something you really should do at the end of any meeting – close the meeting properly and summarize what ever was decided in the meeting. Make sure there is a common understanding of what was decided. This is the moment when you should also ask feedback for your session to improve your facilitation and retrospective planning skills. DialogSheets are a great tool for sprint retrospectives, they offer a clear structure and retrospective plan that is easy to follow and engaging. If you plan to reflect on a longer time span, try to get a neutral experienced facilitator for better results.
Retrospectives are a corner stone for any agile organization and there really is no good reason not to have retrospectives. This was just a quick overview of the process and there are a lot of good resources how to get started. The point is to get started. I would recommend reading Norm Kerth’s book on retrospectives first and then using Larsen & Derby book more as a hand book when planning retrospectives.
There is always something you do better and that is the essence of kaizen. Retrospectives are a great way to plant the seed of Kaizen to the team and to the rest of the company. If you really think that your team is doing so great that you have nothing to improve, then most likely you are the problem.