I recently ran a “get to know your team” session to help a team with lots of new members to better understand each other’s history, motivations, likes and dislikes.
We did a number of exercises including journey lines, what do you value and team flags and we wrapped it up with postcards (insert ref to ant’s post).
We found the “what do you value” exercise particularly effective and I thought I would share the process we used.
This exercise can help to identify differences that might cause friction within the team and find ways to work out any annoying wrinkles in your team dynamic.
The Big Estimation Debate
There have always been, and no doubt always will be debate over estimation; the pros and cons, behaviour anti-patterns and the how and why of it all.
In this post I am not going get into that debate but I want to share with you some experiences I have had with estimation through using the average number of story points as an aid to mid-term planning.
Teams often need to understand when a release longer than a couple of sprints might be completed. Personally I don’t think it is unreasonable to ask “could you give us an indication of when you may be finished so that we can tee up all the other elements of the go-live process”. As software is after all just an element of the whole big picture.
Faced with this question, what kind of options are there?
What does your sprint planning meeting look like?
Are you the “do it as fast as you can” efficiency hounds or the “sit and listen while the tech lead drones on” type, or are you a “real team” who fight for great designs and customer experiences?
Having watched and attended a few hundred of these meetings over the years I have seen good and bad ones. There are a few key elements that, if missed or undervalued, can lead to constant frustrations and sprint failure.
These elements are:
- Understand your project time
- Your signal to noise ratio
- Starting stories when they are not ready
- Sprint planning is not about writing tasks
- Doing too much planning
- Ignoring your velocity
When you are coaching / mentoring there are times when you just get stuck, no matter what you try the message does not get through. You speak to your peers and you come up blank there too.
This happened to me when I was coaching a development team manager, they had sort of adopted some Agile practices but I could never get the rest of the team to go to the next level as their manager was very strong and very loud. While in principle he could see what I was suggesting was beneficial, there was always some reason why he never had the time to implement my ideas. It was extremely frustrating and after six weeks of trying every trick in my book I started to doubt my methods and felt like giving up.
I was reading one of the excellent Poppendieck books (I forget which one now) when an idea popped in to my head. Rather that trying to change the supply, try and change the demand.
We all know or at least we should know that retrospectives are one of the Agile recipe’s 11 secret herbs and spices. It performs a valuable role in the improvement of the team and its practices, as well as throwing up a whole host organisational issues. One step / practice when you are setting the scene in is the check-in.
The check-in is designed to get everyone talking and ensure that tacit approval is not given to stay quiet for the rest of the meeting. Over the years I have tried a number of practices to make this happen:
- The sprint in one word
- If the sprint was an animal what would it be
- Fist of five
- Christmas Haiku
I can’t say enough about how useful story maps are and how essential they are on any Agile project. Jeff Pattonis the undisputed (certainly in my mind) master of the story map and it’s well worth looking at the materials on his site. Jeff summarises a story map as, “A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do. A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.” Story maps really do help you sort the wood from the trees and make a great focus for the whole team when you are trying to get the project context into your head.
Does development process for the stories you build in the first half of the sprint flow nicely, do you have few defects? How about the second half of the sprint? Do you miss things, are there more defects?
The team I am currently working for rocks our current Scrum practices are well embedded and understood. However a pattern has emerged as our velocity increased, we miss key elements / forget design details of the lower priority stories and thus they have more defects than those at the start of the sprint.
So for this sprint I asked the team if we could try a new way to plan our sprints, they agreed and this is what we decided to do.
- Use our velocity as we normally would to help us understand how many stories to initially take in to planning
- We then make an arbitrary split on half the stories rough velocity for half the sprint
This is my second post in my Scrum coaching patterns series.
In my last post I asked for some help with a pattern format that I could follow and at least one person must have read my blog as I now have a shiny new format to follow thanks to Gareth Evans for this.
This is based on Linda Rising and Linda Manns “Fearless change” work, and for anyone not used to this format (like me) I have included the basic format Gareth sent me here. I have modified the purpose of some of the headings, as this a pattern for spotting a pattern as opposed to a solution to a problem outright.
My second pattern comes up all the time, on teams both old and new, I think it causes more sprint failures than anything else. It is my hope that if you can spot this pattern and learn how to avoid it, then you can be even more Scrumtastic.
Earlier this year I was invited to join the Scrum plop, to help write some patterns for the Scrum community, unfortunately the stars were not right and I was not able to attend. It did however help me answer a question that a great friend and fellow Agilist Sandy Mamoli put to me, which was “how do you make your blog posts smaller?”
This got me thinking that I could post some of my pattern ideas as individual posts get some vigorous feedback and test both the pattern and my understanding of Scrum and other Agile ideas.
If anyone could give me tips on a simple pattern format that would be great too.
The non challenging Scrum Master
Inexperienced Scrum Masters regularly forget that they can challenge the team on practices, and adopt a whatever the them says must be right approach instead.
This is most apparent at the Daily Scrum (Stand up). While team members are planning the day’s activities one or more team members will mention activities that both an inexperienced team and Scrum Master will not challenge.
- Doing work not on the visible workspace
- Skipping elements of done
- Starting a new story when they could work on an incomplete one
- Ignoring defects on a story
A few weeks ago I was sitting next to a log fire, sharing a glass of wine with a few like minded individuals chatting about all things Agile, one of the things we discussed was a time when one of the party was a Scrum Master and that they had a team admin who used to collect all the story data and do the typing up for each sprint. My immediate reaction was that of outrage, “how as a servant leader could you, farm off ‘menial’ tasks to someone else, that’s an integral part of the role”.
It got me thinking, am I the odd one out here?
Most of the Agile literature I have read over the years mentions servant leadership, but never really goes in to too much detail. A quick hike to the lazy man’s oracle, (Wikipedia) and as the saying goes “the more you know, the less you know you know”. To help me learn and understand servant leadership a little more, I decided to dissect the Wikipedia commentary and see what emerged for me.
“Robert K. Greenleaf never specifically defined servant leadership but, based on the writings of Greenleaf and others, it can still be defined as a management philosophy which implies a comprehensive view of the quality of people, work and community spirit.”
For four of my six and a half Agile years I was solidly in the Scrum camp, Lean, in my opinion, was already part of Scrum and its influence made Scrum even better. I don’t think that any Agile practice is for the work shy and there is a lot of personal courage needed to get any practice working well. Many people call Kanban an evolutionary rather than revolutionary process (my disagreement of this bland throw away statement will be in a later post), and I think this allows too many people keep the dinosaurs roaming the earth, if the mass extinction event has just happened then apart from the obvious sense of loss , at least you have an empty playing field to start from. Scrum at least with its slightly more prescriptive approach gives you somewhere to start.
About two years ago Kanban for software finally entered my Agile sphere. I initially relegated it to the ideal-for-support-teams division, and sneered at the new kid on the block. But time spent seeing Kanban in action and listening to the wise words of people like Gareth Evans (understanding the cost of delay was a revelation for me) and presentations including “Agile isn’t the point, better is the point,” by Michael Bromley, made me think about Kanban in a more positive light.
Software projects experience a problem called technical debt. In short, technical debt is the result of making a quick and dirty work around (often for valid reasons such as deadlines) which creates rework later.
I recently visited an organisation that had a wall of pain which I thought was an excellent idea as it highlighted the levels of technical debt in the project. This involved a section of the workspace dedicated to items that needed refactoring at a later stage. This made me think about pain and our tolerance to it.
The wall had lots of pain on it and the team did their best to address this pain whenever they could, a commendable exercise for any team.
That said i am not sure how much the pain was actually felt, as i said there were lots of cards and they were not easy to see when the team did their stand up in front of the visible workspace, so they did not feel like they were always on the mind of the team.
Many people’s first encounter with an implementation of an Agile framework is the visible workspace. I find first reactions to this very telling: for some it feels like a natural way of expressing their work and they can see what is happening in an instant, while for others it’s some cards on a wall that don’t look professional and ”what’s this got to do with real planning anyway”. The professional part of me hides that sinking feeling inside when you know how much energy you are going to have to put in to get them to see that Gantt does not always (even rarely) equal a plan that works.
So for those who don’t know what a visible work space is here is a short list of what it is and what it is not. A visible workspace is:
- A focal point for the project team, especially during a horizon
- A representation of the work planned for the iteration
- An easy way to see who is doing what and when
- A planning tool for the team
- A repository for non sprint information too, such as highlighting levels of technical debt
- A living document
- Easy to understand for anyone in the organisation
The Agile manifesto states “Working software over comprehensive documentation” – this seems to be one of the biggest mindset shifts that organisations need to make when adopting any Agile framework. For some people that simple statement brings up visions of chaos, lack of control, and the worst fear of developers doing what they want. At the other end of the spectrum that’s exactly what some people hope it does mean.
If you ask people within most software development teams / companies what they do it is very unlikely that you would get the response “write documents about the products for our clients”. Most responses would be about the latest website or the latest Google hack they are doing. So inherently at an external client facing level we do value working software over comprehensive documentation. Where I believe this value changes is during the production of the working software and the legal requirements from the iron grip of the contract.
A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to beingAgile.
So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.