I also use an additional approach; in the first instance I look to see whether it can be split along its acceptance criteria. Every good user story should have acceptance criteria, and this approach ensures that not only do they exist, but they are also reviewed before we look to split.
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.
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.
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.
I really like Jonathan Rasmussen’s project inception deck as a simple, quick and cut-to-the-chase way of kicking off projects. Overall, I pretty much stick to Jonathan’s content and flow, but sometimes, I use a press release exercise instead of a product box. The idea of refining a product vision through writing a press release has originally been used by Amazon.com as a mechanism to determine whether a product or service should be built.
My client, a New Zealand government department, is in the process of introducing Agile-Lean. They are currently in a trial phase to see if it is for them and during the early stages they’d like to run Agile and non-Agile projects in parallel.
Fair enough, but how to choose whether a project should be run Agile or Waterfall?
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?”
The driving force behind why people start startups is likely to vary wildly across different industries and types of business. For many it’s the promise of lucrative return – from sales of product or selling their eventual company. For some it’s the burning desire to fill a perceived gap in the market – ‘if I want this, surely 3 million other people will want one too’. Perhaps for others it’s curiosity, or a need to be in charge of their own destiny, or all of the above.
One of my current clients, a large government agency, have recognised that their current monothilitic waterfall approach doesn’t work all that well and are trying to decide whether to change their delivery approach to Agile or “just” Iterative (mini-waterfall style).
Following last week’s interview with a newly-minted Scrum Master this week I have had a conversation with developer Mateusz Udowski. We talked about how SilverStripe’s adoption of Agile and Scrum have affected him and why he thinks SilverStripe is now more intelligent as a whole than it was before.
Six months ago SilverStripe, an open-source Content Management System provider and Wellington web agency approached me to help them improve the way in which they deliver client and open source projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like (fixed scope/fixed price) approach and introduce Scrum with its focus on client-driven iterations, early feedback and continuous improvement.
Silverstripe have asked me to interview some of their staff about the transition to Agile. The original posts can be found on Silverstripe’s blog (Sam Minnée, Aleksandra Brewer), below are selected highlights from the interviews.
The first big task of getting started is updating all the various bits of online information that describe who I am and what I do. So far I’ve kept my Facebook and Twitter presence to be fairly personal, so it’s not relevant there. But Linked In is a very important business marketing tool – not just for any relevant contacts to my new business, but also to maintain local and international networks and connections relevant to my recent or future work. Then there are business cards to be printed, blogs to update and an identity to create.
Choked at the first hurdle.
Last week I presented to Flex and Cold Fusion Developers at cfObjective in Melbourne about Agile technical practices. As several other presentations dealt with practices such as TDD and unit testing I chose to focus on two areas I have become very passionate about during...
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.”
“When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”
— Nanny McPhee (via Lyssa Adkins)
I am an Agile coach and the goal of my job is to put myself out of a job.
My mission is to teach people Agile and to make sure they understand and correctly apply Agile values, principles, frameworks and techniques. This is quite a big deal as Agile often forces us to change the way we work on a daily basis; how we organise our work, how we collaborate, which tasks we perform and how we communicate with each other and the rest of the organisation.
Checklists have a somewhat bad reputation in the Agile world, probably because they “smell” of too little self-organisation and too much process. I find this reputation is entirely undeserved as they can be extremely useful as a memory aid, or to visualize a workflow.
Checklists play an important role in areas where missing steps can have disastrous consequences, such as in hospitals or airplanes; or in situations where people are likely to forget individual steps, such as when they’re stressed and tired; or while learning a new process or way of working.
At work we mainly use checklists when we want to introduce a new workflow and need to make sure we don’t forget about the process or any of its steps.
Here’s an example of our checklist for the sprint workflow and working with user stories:
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:
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.