This session by Lyssa Adkins was one of the highlights of the conference for me. The practices that were introduced were immediately actionable while being innovative and different to other approaches I’d seen. The simplicity of these techniques is what makes them appealing while they address a very real issue, how do we ensure that all team members are represented in team meeting? We have all been in meetings dominated by a couple of strong characters. Often the smartest ideas are in the heads of someone who either is not willing to fight for air time or does not believe that the idea is sufficiently well formed to be presented to the group.
The techniques we applied were based on the scenario of a requirements meeting. The idea here is that a team is working on a product and needs to come up with the next release of stories. Each step described below was executed and the ideas generated were increasingly “left field”. Lyssa’s assertion was that many teams have achieved a level of practice that successfully deliverers mediocre results faster than was the case before adopting agile. The “left field” ideas were seen as valuable in the identification of new and innovative ideas that make the difference between a mediocre product and an exceptional one.
Step 1: Round table discussion
As a group we discussed possible stories and wrote them on cards. This proved to be slow as we delved into detail and semantics in the wording of stories based on the product theme we had selected. This approach is common in teams and does effetively identify key system uses.
Step 2: Card storming
In the next exercise we individually wrote stories on cards. This introduced a risk of duplication that was easily filtered out at the end. A key benefit here was the variety of stories and the quantity generated. We had successfully engaged everyone around the table.
Step 3: Collective authoring
I struggled for a name for this (Lyssa may have one). Each team member writes the first line of a user story on a card, “As a _____”. The card is then passed to the team members left so all cards have moved to a new person. Then the next line is written “I would like _____”. The cards are passed again and the final line is added “so that ____”.
This is where innovation really begins, as stories become more novel the energy in the room increases. However, I felt that of the three approaches this was least effective in producing valuable stories. On the other hand this set the stage for Step 4.
Step 4: Collective authoring 2
As in step three cards were passed round the table with the story being written a line at a time. The difference here was the order; first the value, second the user, third the feature. This provided some really novel features in addition to some spectacularly silly options. As a team building exercise this struck me as valuable. As a means for enabling innovation it has to be tried.
Each of steps 2-4 was executed with no conversation; hence the title silent work techniques. All team members were engaged and able to contribute fully and equally.
On a personal note, I am more comfortable in conversation than in card storming. I am slow to get going with ideas and benefit from the noise of group conversation (as friends will tell you I don’t struggle to be heard). However, I have recognised the element of teams that struggle to engage and I do believe that as a team we can miss out on ideas if we don’t provide space for contribution.
Technorati Tags: agile2010
August 20th, 2010 in
Agile |
No Comments
This session was run by Arto Eskelinen and Sami Honkonen and was oriented about using the GROW model as a guide for a coach when working with an individual or team.
The session was opened by a review of the responsibility of a coach. This was described succinctly to be to raise awareness and a sense of responsibility rather than do what is often most natural and provide solutions.
Grow is another model that I have been aware of for some time but not previously applied in anger. This session was expertly facilitated with ample time for group discussion as we worked to develop questions according to the model.
GROW offers the following conversation framework:
- Goal: what is it you really want?
- Reality: where are you right now?
- Options: how might we achieve the goal?
- What: what is it we are going to do now?
The first focus of the session was on forming questions. By focusing on what, when, how much, how many type questions. These types of questions provide room for useful information with lesser likelihood of triggering a defensive response. This is unlike “why” which will often be interpreted as a challenge or as threatening to the receivers competence.
For each step in the process Arto and Sami offered specific advice. For a goal we must identify something sufficiently high to motivate while being achievable. There are clear applications of NLP goal setting practices here too in term of ensuring a goal is positive, and sufficiently specific (see well formed outcomes). The NLP practice of chunking up / down provides a mechanism for seeking a goal at the right level for us to act on.
When considering the reality aspect, seek to test assumptions, explore different points of view / angles and the feelings that result. With options the key is to provide enough difference to create choice. Two options is not a choice so much as a dilemma. If finding new options is hard try generating less plausible options and challenging limitations in this way we may expose the beginnings of a new option. Finally, at the what step we must establish momentum. By considering when actions will take place and the observable effect that we expect we ensure a shared understanding and shared expectations. Finally by identifying obstacles we hope to provide sufficient support and to avoid the actioned individual or group from stalling before getting going.
The format of the session was, I felt, very effective. Each group began with an issue being presented to them, the brainstormed candidate questions then selected one, then the same with answers, then follow on questions etc. In this way we were able to consider how new information arriving would influence our direction.
Technorati Tags: agile2010
August 14th, 2010 in
Agile |
No Comments
In her session on the Agile Organisation, Jean Tabaka describes some of the models that have been used during her time with Rally. The honesty of this session was key. Jean described how models from a variety of sources had been tried, how they had been adapted, which had remained and which had been dropped.
I’ll try and capture some of the models Jean described and provide relevant references. I’ll also bring together some key “sound bites” in the hope that these provide insight into the mind set and values that underpin the application of these models.
Read the rest of this entry »
August 13th, 2010 in
conference | tags:
agile2010 |
No Comments
Thanks to everyone who attended my session yesterday called retrospective for an agile coach. This session was designed to provide a catalyst for conversation and reflection about the role of a coach. While the timing was off (for which I apologise) I hope attendees found the discussion valuable and were able to use the conversation to reflect on their own experiences.
One of the themes of the conversation was the importance of visioning. I described a scenario where a project suffered and ultimately was cancelled and we began to consider how effective visioning might have influenced the project. I suggest that, while we like to think about success, in this case the project was destined to die. A successful visioning exercise would have either fundamentally changed the shape of the project or have killed it early.
The last thing we need is to expend valuable time and effort on what DeMarco (I think it was him) called zombie projects.
I’ll write more here on the subject of visioning another day.
This week I’m at the agile 2010 conference in Orlando Florida. This is the first time at the major international agile conference for me so I’m keen to see what I can learn.
This really is an opportunity to hear first hand what our industries thought leaders and authors are thinking following 10 years of practicing agile in all manner of circumstances.
As well as meeting up with old friends made at various UK conferences and gatherings the conference provides an atmosphere in inquiry and interest perfect for sharing ideas and experiences.
I’ll be presenting two talks at the conference, the first is a retrospective on experiences of coaching teams to introduce agile principles and practice, the second is on the subject of business analysis practices, for this one I’ll be co-presenting with Gary Jones (a colleague of mine from Valtech).
I’ll try to post back here often with highlights from the conference.
August 11th, 2010 in
conference | tags:
agile2010 |
No Comments
Agile practice irrespective of flavour (Scrum Kanban XP …)can often be reduced to:
- Work in small batches
- Deliver often
- Build the most valuable chunk first
And it’s the “value” bit that can get us in trouble.
How do we determine which is the most valuable bit? Particularly early on in a project we need to be careful about how we prioritise. Do we just get a bunch of business folk to fight for their favourite features or do we have some hard won lessons to apply from many years of technology project management?
One of the first projects I was responsible for was fixed scope and fixed price. The customer was documenting requirements to be handed into the “agile” development team who built and tested software prior to a traditional system test cycle. Not very agile!
However, we benefitted greatly from the rhythm or scrum, the rigour of agile engineering practice and the predictability the the planning and tracking approach provided.
Most significantly, by taking the Product Owner role I was able to prioritise according to my own definition of value. Put yourself in my seat, you work for a software consultancy, it’s your first project and it is fixed everything, what makes one feature more valuable than another? The answer is risk. When everything is fixed value is in the reduction of risk. In fact I combined prioritisation according to risk with other engineering considerations such as profile of the work to bring the project to a successful conclusion.
So what about other interpretations of value? I’ve been helping a client with a project initiation over the past couple of weeks and found myself using the word uncertainty a great deal. It seems that driving out uncertainty held a great deal of value in that context. In fact, when kicking of a project we look for information generation first, then seek to identify key risk areas and mitigation strategies such as finding new stakeholders or driving out technical risk with proof of concept work.
Uncertainty isn’t new; I often use the “cone of uncertainty” model to express the value of reducing uncertainty. As wikipedia will tell you, this model is primarily concerned with project estimation. At the beginning of a project, skilled estimators may have a factor of 4 error in either direction. Over time error should rapidly reduce as information arrives and the project progresses. This dynamic is known as the Cone of Uncertainty and is the inner line on the graph.
The outer line is the cloud of uncertainty. This is what could happen if uncertainty is not driven out of the project. Right to near the end of the project there is significant error in estimating the size due to missing information.
When we execute agile projects lets not forget the value of driving out uncertainty. This isn’t an excuse to analyse everything to death. Our goal is to recognise where the uncertainty that matters is hiding. Those innocuous features that come along and prove the architecture is flawed are a prime example. We must do enough to understand the risk we are carrying while being sensitive to the cost of gathering detailed information pertaining to speculative requirements.
Technorati Tags: cone of uncertainty
In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their approach (when working with Scrum) to prioritisation of stories by the product owner within a sprint.
Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.
By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.
As is so often the case I feel that I fall between these two camps.
- I believe in an empowered team who pull from the backlog
- I believe in the team making a commitment to a sprint scope
- I believe in the team self-organising around moving that scope through to releasable product
But, there is always a but, these things don’t preclude prioritisation.
We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.
When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:
- The team is challenged to find ways to move stories to Done faster
- The team is encouraged to collaborate and help each other out in favour of picking new tasks
- We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
- Where a sprint commitment is missed we loose 1 story rather than a bit from each story.
So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.
For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?
February 3rd, 2010 in
SCRUM | tags:
Prioritisation,
SCRUM,
WIP |
1 Comment
Many of the practices that we apply in agile development teams emphasis deferring commitment. This is one of the ways we stay agile. If we have written a sentence on a story card and subsequently decide we don’t need that story we can rip it up, very little has been lost. Compare this with costly requirements specifications, a small change can trigger significant re-work.
In the same way, when specifying a user interface it can be helpful to defer commitment while expressing the need succinctly. Often we can use white boards and/or paper mock-ups to develop screen flows in meetings with customers. This can help us play with alternatives and walk through scenarios while avoiding the cost of mocking up in html or photoshop.
Balsamiq Mockups offers the logical next step. By retaining the style of a paper mock-up we can avoid becoming too attached to one design. A slick user interface helps us build screens quickly and provides most of the components we are likely to need.
However, for me the killer feature is the confluence integration. I use confluence every day, many of my clients use confluence for project documentation, this integration means that the documents can be found by all concerned, edited in place and version controlled.
Technorati Tags: Agile Requirements, Balsamiq Mockups
I should start this post with an admission – I do not claim credit for any original thought here. What follows is taken from my own notes and has been accumulated over a number of years. I most recently tweaked my own notes and the way I explain this stuff after hearing Jeff Patton’s talk from the UK Lean Kanban conference on infoQ.
The way I think of splitting user stories is through identifying axis. Some examples of axis are:
- Steps in a workflow
- Usability
- Quantity of data
- Asymmetric value
- Stakeholder needs
Steps in a workflow
The first of these is fairly self evident. On a recent project we had the need to implement a user story to purchase an item. This fell into an initial workflow design and mock-up stage followed by 4 user stories relating to the four stages of the workflow, checkout, select shipping method, submit order, order confirmation. This approach enabled us to deliver working features based on mock-ups followed by iterative improvement.
Usability
Another approach to the same problem could have been to split along a usability axis. This would involve and early “ugly” version followed by iterative usability improvements. This approach can be more effective if the screen design is novel and uncertain or the technical risk around order submission is being brought forward as a risk mitigation exercise. A further usability axis would be to separate core functionality from enhancements such as auto-completion and other AJAX magic.
A further example from the same project that comes to mind is a search capability, initially searching was by full words only on one field, gradually the back end was enhanced to do partial words and check multiple fields. At the same time the search results view was being enhanced to enrich the user experience.
It is in this category that we see Patton’s considerations of Bare Necessity, Capability & Flexibility, usability, performance, sex appeal manifest. His final axis is Safety which more clearly maps to stakeholder needs below.
Quantity of data
Quantity of data can be an issue where it significantly impacts the size of a task. For example where a datasource differs. It may be possible to establish a users workflow while limiting the variety or variation of inputs or scenarios. An example might, we limit a registration form to accepting only minimal customer details or limiting a report to show only a subset of the data. The latter approach may allow some proof of function and review of layout earlier than if all data sources / types / fields were considered.
Asymmetric value
Value is a core consideration with user stories. It may be worthwhile considering how the value of the user story is gained. I worked on a system some time ago which was incrementally adding features in order to retire an older system. Our key goal was to minimise the users interaction with the old system. The user story under consideration was along the lines of ”create and trade financial instruments”. It turned out that while at first glance these were an atomic unit the users would trade instruments many more times that they would create them. Thus, we could reduce the users interactions significantly by providing the trade facility requiring the users to, in the short term, create instruments through the older system.
Stakeholder needs
Despite the name “User Stories” a stakeholders needs can be represented as a user story. During development it can be useful to view a user story from the perspective of security, operations, finance (and others) where one of these places a significant burden on a user story it may be appropriate to separate the two goals. An example of this can be as simple as data validation e.g. post codes or Captcha fields which do not benefit the user but some other stakeholder.
If all else fails
We could always fall back on using architectural lines to split a user story or breaking out a component that needs to be built. This approach is often at the top of the list when developers begin to consider splitting stories. I prefer to leave this as a last resort, we shouldn’t deny that it is an option but as my experience in splitting these things has increased it is a resort that I find myself reaching for less and less.
Technorati Tags: Agile Requirements, User Stories
