Category Archives: Agile
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
I recently had a chance to facilitate a retrospective for a fellow team at my department. That team had been through a lot of changes and the most longest serving member had been there for less than a year. So it really looked like a good time to invest a bit of time to really open the conversation channels.
I had not facilitated a proper retrospective in a long time and this was a completely new team for and I hardly knew anyone of them so I did have few concerns.
- Would everybody feel confident enough to speak up and voice their concerns?
- Would they really engage and concentrate on the topic at hand?
- Would I be able to explain the exercises properly after such a long time and in English?
To address the first concern I decided to do a safety check in form of a ESVP -vote. I also wanted to underline the purposes of the retrospective and what we wanted to achieve. I also planned to make a point about being fair / just and show the little cartoon.
For the second point I decided to write some slides to explain the exercises. I usually prefer to have as little technical devices in the room as possible and I like to make the point about leaving mobile phones and laptops aside, but this time I decided to make an exception.
Here is the plan I made for this retrospective that was scheduled to take 3 hours. Apart from the exercises I will share my time tracking and some comments how I feel it went.
1. Set the Stage
1.1. Safety check / ESVP -vote
To understand how people felt about this retro I wanted to see how comfortable they felt.
How did it go?
Luckily the results were really encouraging and only one gave an S and everyone else gave an E so I the results were really encouraging,
1.3. Unlikely Superheroes
I borrowed the idea for this exercise from one of my favorite tv-shows: whose line is it anyway. In that show comics improvise and give each other silly superhero names and then act out a scene trying to solve a silly crisis that the audience gave them. I changed it a bit and only ask each attendee to think about their role and contributions to the project and give themselves a superhero name and identify their superpower and weakness. People tend to be really good at coming up with funny metaphors and this sounded like a fun way to get the people thinking how they see themselves in the team and also identifying their own shortcomings in a relaxed and humorous manner.
How did it go?
I think it worked out quite fine and we got some pretty funny names and superpowers coming out and few laughs as well. This exercise definitely helped to create a relaxed atmosphere and we were ready to move on. In general the 1. stage took only 15 minutes.
2. Gather Information
Timeline tends to be my de facto way of gathering information of what has happened. This time planned to give the team 10 minutes to write down 5-10 events or things that each found meaningful and that had an impact on their moral or attitude towards work (each on their own, so everyone wrote their own notes). After that I would ask each one to step forward and quickly explain each note before putting it on the timeline I would sketch on the whiteboard. Apart from time axis the timeline had moral axis meaning that events that were considered positive would be higher and negative events lower.
How did it go? (time spent: 40 minutes)
In general these seems to be an instant hit. Everyone always has plenty to say and this is a great way to make everyone participate. Even the guy who had been with the team only for 2 weeks had something to say. Some even had way more than 10 tickets and as we seemed to have plenty of time, I let to put them all up.
(break, 15 min)
2.2. Identify patterns
Next I would ask the them to form small teams of 2-3 people and then to have a closer look at the timeline to identify patterns and themes that emerge. Then we would together list them on a separate walls and group and merge them to one combined list of higher abstraction level themes and topics to talk about. When it comes to timekeeping I did drop the ball. This took a lot more time than anticipated.
How did it go? (time spent: 1h 00min)
In general the small teams got underway fast and started to pick out themes and patterns. Then when we wanted to merge the list from each team the conversation really started booming. There seemed to be endless possibilities to discuss and pretty much everyone seemed to be participating.
2.3. Point voting for top 3
After all the topics were discussed we would need to pick top three for further analysis. Everyone would get 3 votes and the top 3 of topics would then be picked.
How did it go? (time spent: 10min)
Well it’s simple enough and got the job done.
3. Generate Insight
It’s a combination of 5 why’s and mind map. The idea is to create 3 teams (1 each topic) and have them analyze the reasons leading to current situation regarding the topic. The reason as many and they are not linear so what you end-up with is a mind map like graph of reasons. I still recommend following up each initial path to at least 5 whys.
How did it go? (time spent: 10min)
4. Planning Future Actions
4.1. The perfect world
This inspired by Toyota Kata and the idea is to think how things would look if they were perfect.. This exercise also concentrates on the topics chosen in earlier exercise. I find it very valuable to think where you want to go before trying to come up with steps to get there.
How did it go?
Skipped due to lack of time.
4.2. Planning game (planned duration: 20 minutes)
Ask teams to plan 2-.3 concrete steps to get slightly closer to the perfect situation in previous. In the end present the tasks to the team and take responsibility.
How did it go? (time spent: 10min)
At this point we were really stressed with time so I had to simplify and push the timelimit. In the end we did have action points for every team and we did have some pretty good ones.
I planned to write 3 questions to a white board and then ask each to write their answers on a separate note. Here are the questions:
- What did you like best in this retro?
- What did you dislike?
- On a scale from 1 to 5 (1 great – 5 horrible), how bad waste of time was it?
How did it go? (time spent: 5min)
Most seemed to want to give the orally and publically saying mostly positive things. Few actually gave me their feedback on paper. Mostly people seemed to like it and the criticism concentrated on lack of time for the planning and the poor time management.
The criticism over time management was spot on and that seems to always be an issue for me. Somehow I always get excited when the team really starts to talk about things and it’s really hard for me to stop it, especially in a case like this when I feel that this was the first time the team actually talked about non technical stuff properly. Still it would make sense to have some proper time for planning the actions to be able to validate and review them properly.
Sometime ago I got a confirmation for both my conference trip to one of the most important agile conferences in the old continent – XP2014 and that my suggestion for lightning talk was accepted. I plan to do a quick introduction about Emergent Leadership which I blogged about the my previous post.
Lightning talk should be a perfect for this as what I want is to stir a bit of conversation and question static team structures and roles. Agile is not what you do, it’s what you are.
It does not hurt that this conference is hosted in historically one of the most intriguing cities in the world.
So what I still need to do is to clarify my thoughts and how I want to present the topic. 5 minutes is not much, but it can be plenty if well used.
Managing and leading are two very different concepts, but many times you see terms like “manager” and “leader” used interchangeably. I personally like to define them very differently and in my opinion there is a very clear distinction.
In short “managers” are appointed and leaders emerge.
Managing refers to managing conditions and good managers create condition where leadership can naturally emerge. Some people are natural leaders and they will naturally take the lead unless their leadership skills are suppressed by management.
Leaders are very context dependent. In a software team during different development phases different people can emerge as leaders and even designing different parts of the system it might well be that the people who best understand the requirements and situation naturally take the lead.
A good manager should understand to cede control when someone else is better fit to lead. Arbitrarily holding on to power will only interfere with teams capability to perform. Ceding control requires a confidence and trust in the team.
Emerging leadership is a natural phenomena. Take a travelling flock of birds for instance. A wedge of cranes has a leader, somebody has to fly in the peak. The leader position is however circulated naturally.
The form of the wedge is fairly stable, but some other flocks change the form dramatically and peculiar forms and patterns can emerge. “When birds fly in flocks, they often arrange themselves in specific shapes or formations. Those formations take advantage of the changing wind patterns based on the number of birds in the flock and how each bird’s wings create different currents. This allows flying birds to use the surrounding air in the most energy efficient way. ” (http://birding.about.com/od/birdbehavior/a/Why-Birds-Flock.htm) Should an agile team think it’s form should stay constant.
Leadership implies followers. When it is not by authority as when manager tells his team to do something, its naturally good measure to check if the actions are agreed upon. If you have a good idea and people are willing to follow you because they agree with you, that makes you a leader.
Emerging leadership is an ongoing self organization activity by the team. Self organization is one of the fundamental agile -principles, but it’s not always understood as an ongoing process. Emerging leadership is a natural phenomena in a truly self organizing team. Agile team should be more like a flock of bird that is prepared to change forms to best benefit from the “currents” every team members skills create any given moment of time.
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/.
The good people, the important people are called to meetings a lot, they spend lion share of their time sitting in a meeting room with other important folk. They are always busy and occupied. They spend their time in important meetings, because they are so important that the meeting would be meaningless unless they attended. As a driven, motivated and ambitious being you also want to be considered important for the company. After all having your plate full meetings conveyances your importance to company and is by far the most important metric for your own career development.
“I participate in a meeting, therefore I am important”. –Rene Descartes
They have their calendars so full that they don’t have time to do actual work so they sit at the meetings with their laptops doing the work they should have done days ago and in the process don’t actually pay attention to what ever that meeting was about. This will prolong the meeting meaning that they will be late for the next meeting which will then prolong even more. Then follow up meetings will be programmed. This vicious circle tends to get worse and it can even be contagious. Some people tend to invite even more people to these meetings robbing them the precious productive time and it is surprisingly hard to say no to these invitations.
“One cannot participate twice in the same meeting” – Heraclitus
Busy people are not available people .They are not there to help and tutor younger colleagues, they are not present to offer their opinion or expertise when problems arise. They are too occupied to do their jobs.
“We participate in the best of all possible meetings” – Gottfried Wilhelm Leibniz
Unfortunately busy people does not equal productive people. The really productive people fill their calendars with nothing so they have time to actually be productive. These productive people posses the most productive commodity: time. Time is what they need to get the job done.
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.
There are certain things that you seem to miss just when you don’t have them. After experience some rather obvious problems in communication you finally see how much you value the. Last fall I was part of a team very we simply did not share a language. Officially the language was English, but one member of the team was less than proficient in it and prefered to talk in his native tongue unless we were in direct talk or in an “official” meeting settings.
This of course lead to situation where a lot of communication in my team was conducted in a language that I personally did not understand. Not only did I feel left out, but I also missed out on a lot of something that I call “passive” communication, I did not know what they were talking about, whatever the problem was, what conclusions they got etc. All that is hugely important as only a fraction of all relevant communication in a project happen during “meetings”. Meetings should be avoided anyway.
Small but important design decisions happen throughout the day and these are the decisions that in the shape how the project ends up looking, specially from the code point of view.
Geographical distribution is equally bad or sometimes even worse. It is very easy to disconnect from rest of the team and get sucked into your own silo even more. The counter this it is essential to communicate at least via instant messaging channel that should be widely used within the team and the nature of the banter should not be too official. Jokes should fly and funny links passed essential. The team needs to bond.
This leads me to argue that working from home works best in cases where the team is well functioning and barriers of communication are already removed. Working from home does have some obvious benefits
- less time in commute
- calm environment
- quality of life can be better.
I am not against that, but I think that at least at the beginning of a new project or when joining a new team the team should sit together to get to proper and productive mood.
Well, not any situation is perfect and as a professional you always have the responsibility to do your job and contribute even if not everything is perfect. Voicing your concerns and making your criticism is the first step, but people who actually act instead of just complaining are so much more valuable. Nobody wants to sit next to a cry-baby.
Too much is too much and sometimes it just might be the best thing to take a cue from Daniel Temme, but just don’t do it too often. I have personally discarded a client for having too many jobs during the past 5 years.
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