If You Chase Two Rabbits, You Won't Catch Either
Need I say more? No, thought not :)
Kelly.
Lean Principles #1 - Eliminate Waste
Lean software development advocates 7 lean principles, the first of which is 'Eliminate Waste'.
Sounds obvious really. How many people came to work today to spend their time on waste? Some maybe! But not most. So what is waste, and how do you identify it?
Some waste is obvious. But other forms of waste are more difficult to spot or to solve. I'm sure in most organisations it's sometimes very difficult to identify what is waste and what is not. Some processes or conventions might seem wasteful, but actually provide real value elsewhere in the organisation, or prevent other forms of waste from emerging later. Other activities may seem valuable, but actually do not really result in any real value.
As I mentioned in my opening post about the 7 Key Principles of Lean Software Development, lean development originated from lean manufacturing and the Toyota Production System in Japan. In these methods, they identified 3 general forms of waste, which they called in Japanese - 'Muda' (meaning unproductive), 'Mura' (unevenness, inconsistency) and 'Muri' (over-burden, unreasonableness).
In doing this, they also identified 7 particular types of waste in manufacturing:
- Over-production
- Unnecessary transportation
- Inventory
- Motion
- Defects
- Over-processing
- Waiting
In lean software development, Tom and Mary Poppendieck translated these wastes into some things more specifically relevant to software development. For instance:
- unnecessary code or functionality
- starting more than can be completed
- delay in the software development process
- unclear or constantly changing requirements
- bureaucracy
- slow or ineffective communication
- partially done work
- defects and quality issues
- task switching
A common agile development practice is the 'retrospective', which is the process of the team meeting after each short iteration to discuss what went well, what didn't, and what could be done differently in the next iteration.
This iterative process of learning and continual improvement is an important part of identifying waste and eliminating it. In my experience this is one of the key benefits of agile software development.
Traditional software development and project management methods advocate a 'lessons learnt' process, but it generally takes place at the end of a project. By this time, things are forgotten, people have changed, the context has changed, and the team may be disbanding to move on to another project. As a result, the team may never really get a chance to put these learnings and changes into practice.
With agile development, these retrospectives enable the team to make small improvements regularly, and tackle changes in manageable, bite-sized pieces that can be actioned immediately.
Identifying and eliminating waste should not be a rare event conducted by process re-engineering consultants every few years. It should be a regular process, built into regular iterations, determined as much as possible by the team, and tackled in small, timely steps.
Making improvements little-but-often in this way creates a culture of continuous improvement - a learning environment - which for some organisations could potentially give you the edge over competitors.
So if you're not doing it already, I urge you to hold regular retrospectives. This is one agile development practice I can heartily recommend. Try to foster lively but healthy debate, critical but constructive feedback, and try to drive out meaningful and actionable improvements that actually help you to frequently identify and, more importantly, eliminate waste.
Kelly.
Photo by David Enker
Keep In Touch With Email Alerts
For some time now, I've had the facility on this site for people to keep in touch with my blog posts through email alerts, but I've never really pointed it out.It's pretty cool, because with this new technology called email :) you'll never miss a trick!
If you do sign up for email alerts, I promise I will never sell or disclose your email address to third parties, because I hate spam as much as you do.
Sign up here -
Kelly.
Photo by Coletivo Mambembe
7 Key Principles of Lean Software Development
I haven't blogged much about lean development. I'm not an expert on lean, but agile development is a great example of lean thinking in action. So I thought it might be interesting to blog a bit about lean software development, and how I see it...Before you can really put anything into practice, I think it's important first to understand the key principles.
Lean principles originate from the lean manufacturing approach also known as 'just-in-time production', and pioneered by Toyota. Lean manufacturing is a process management philosophy that transformed the car manufacturer's approach to building vehicles.
Lean software development originated from a popular book by Tom and Mary Poppenieck that translates lean manufacturing principles to software development. Tom and Mary's books, training, and talks at various agile conferences, have resulted in lean software development becoming widely accepted within the agile development community.
So what are the 7 key principles of lean software development? They are:
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimise the Whole
Over the next few weeks, I'll blog about each of these lean principles in turn, explaining it as concisely as I can and giving you my personal perspective on it...
Kelly.
Looking For An Agile Sponsor
Since starting this agile blog back in 2007, I have spent countless hours writing original content and trying to help the agile community by describing some of my personal experiences of implementing agile methods such as Scrum, XP (Extreme Programming) and Lean.
The site has gained a significant following in that time (over 5,000 subscribers and many more visitors), which has been really pleasing and I regularly receive positive feedback from people all over the world that my blog has helped with their own implementation of agile.
Off the back of this blog, I also started an online agile community, which is reasonably active and is helping people to find answers to their problems from other people who have run into the same or similar problems when they were implementing agile.
But now, to be honest, I find myself at a bit of a junction.
In the last 3.5 years, running this blog has demanded a lot of my spare time. So now I think it is time that I found a Sponsor to support the site on an ongoing basis.
As you can see, I have a few advertising positions on the site, as well as a background and places in the sidebar where I can provide links to relevant organisations. If you are interested in taking any of these positions to raise the profile of your product/organisation, and to show your support for the agile community, I would obviously be very happy to hear from you.
If you're interested in discussing this further, please email me on allaboutagile@gmail.com.
Many thanks
Kelly.
Agile User Stories, Themes, Epics, Features - What's The Difference?
A recent comment on one of my blog posts asked about the difference between agile user stories, themes, epics, and features, and about the relationship, or hierarchy, between these terms?Admittedly it is a bit confusing, as these phrases are often used quite interchangeably (at least by me). Here's my take on what the difference is...
A user story may include several features. For instance, 'As a user, I want to search for a job, so I can find my next career move' might include various features, such as simple search, advanced search, faceted navigation, sort, filter, sign up for email alerts, etc.
A user story this big would be considered an epic, since it's a very big user story. Epics can (and ideally should) be broken down into further user stories to make them easier to handle.
Each of these features can be broken down into tasks. For instance, the advanced search feature (which could also be expressed as a user story of course) might include back-end development of the search index, front-end development of the search box, an API to find the most relevant search results, front-end development of the results page, writing test cases, executing the tests, configuring the search servers, etc.
Themes, on the other hand are just a broad way of describing an area of focus. For example, the theme of the next 2 sprints might be 'job search', after which it might be something else, say 'apply for a job', followed by 'CV database' for instance. Each theme would probably contain several epics or many user stories.
In terms of hierarchy, I think these aspects of the Product Backlog can be defined in as structured or as loose a way as you think is right for your project. I don't think there need to be any hard and fast rules on this.
For anyone finding this terminology a bit confusing, I hope that helps!
Kelly.
Photo by TheBusyBrain
'Ads Are The New Tip Jar' - By Seth Godin
Seth Godin is one of the most famous bloggers around and has authored numerous books on the subject of marketing. I just ran into this old post of his, 'Ads are the new tip jar'. It's an interesting, but controversial concept.
At first the idea certainly appealed.
Bloggers, like myself, spend a lot of time writing unique content and promoting it, usually for little financial reward but because bloggers are sharers; people who get genuine pleasure from sharing knowledge and opinion, and helping others.
Advertisers are fighting for attention. The attention deficit, in this age of information overload, is a real problem for producers of content and advertisers alike.
Google say you mustn't ask people to click on your ads. It's strictly against their policy. But what if you ask, "Please click on my ads, but only if they're potentially of interest and relevant to you"? Isn't that what advertisers want?
In a follow-up post, "Beating the status quo", Seth apologises, but defends his original post which came under quite a bit of criticism.
Even in the world I work in, large media companies have similar problems with the monetisation of online content. Rupert Murdoch of News Corp (the world's second largest media conglomerate) is tackling the problem head-on (see 'Murdoch on Leading the Charging Charge').
At 79 years old, and with a net worth of about $6bn, I think it's amazing that he still has the energy to fight this battle for his companies. His views on the subject of paying for content have been well publicised and we are just about to see whether or not people are willing to pay, at least for news, as he puts up his pay wall on The Times web site.
The world's media companies, and perhaps even bloggers, are watching with baited breath to see what happens. If he's successful, it could change the economy of the internet forever. Or will people simply go elsewhere?
Kelly.
IPC Media Sponsoring Agile Awards
I'm delighted to announce that IPC Media - the company I work for as Web Technology Director - has agreed to sponsor the first ever Agile Awards in the UK.We're sponsoring the award for Best Agile Team - something that's close to my heart because teamwork is such an important part of agile software development. Regardless of any particular agile methodology, people are the most important aspect of any project, without a doubt.
I'm so pleased that IPC has been able to support this event. Regular readers of my blog will obviously know I'm a keen advocate of agile methods, and IPC has benefited significantly from the implementation of agile.
As per my recent blog post, I'm also speaking at the Agile Business Conference about IPC's experiences with agile. I hope it will be an interesting insight into one company's approach to agile, and how it's transformed our digital division into a really great place to work!
If you're not familiar with IPC Media, we produce over 85 iconic brands, with our magazines alone reaching almost 27 million UK adults while our online brands collectively reach 20 million users every month. Just a few of our top web sites include: goodtoknow.co.uk, marieclaire.co.uk, look.co.uk, instyle.co.uk, housetohome.co.uk, nowmagazine.co.uk, trustedreviews.com, nme.com, mousebreaker.com, ybw.com, whatsontv.co.uk, wallpaper.com, womanandhome.com, horseandhound.co.uk, countrylife.co.uk, cyclingweekly.co.uk, decanter.com, whatdigitalcamera.co.uk, nuts.co.uk, loaded.co.uk and many more!
Why not show your support for the awards too, either by booking a table at the dinner, and/or sponsoring an award!
Kelly.
Agile Awards 2010 (UK)
The Agile Business Conference is sponsoring the Agile Awards 2010 – the inaugural Awards for the UK Agile Community.
There will be 10 Awards recognising the People, Projects and Products that have contributed to Agile in the UK.
Nominations for each Award are invited from all members of the UK Agile Community. Winners will be announced and Awards presented at the Agile Awards Dinner alongside the Agile Business Conference in London on 5th October.
Full details of the Awards Categories, Nominations and Sponsorship opportunities can be found at the Agile Awards Website: Agile Awards 2010
The Agile Awards 2010 is a not-for-profit event organised by Connections Agile Services in association with the Agile Business Conference. Any profits will be donated to the charities Shikamana School for Orphans in Kenya and the Macmillans Cancer Support.
ABC Super Early Bird rates available until 30 June and Early Bird until end July:
There will be 10 Awards recognising the People, Projects and Products that have contributed to Agile in the UK.
Nominations for each Award are invited from all members of the UK Agile Community. Winners will be announced and Awards presented at the Agile Awards Dinner alongside the Agile Business Conference in London on 5th October.
Full details of the Awards Categories, Nominations and Sponsorship opportunities can be found at the Agile Awards Website: Agile Awards 2010
The Agile Awards 2010 is a not-for-profit event organised by Connections Agile Services in association with the Agile Business Conference. Any profits will be donated to the charities Shikamana School for Orphans in Kenya and the Macmillans Cancer Support.
ABC Super Early Bird rates available until 30 June and Early Bird until end July:
Agile Business Conference 2010 - London, Oct 5-6th
The next Agile Business Conference in London is being held on 5-6th October at the Inmarsat Conference Centre.The theme of the conference this year is 'The Naked Truth'. As agile development has been adopted by many organisations and as it begins to mature, this year's conference aims to explore the realities of agile at both an organisational and project level, in an attempt to really get behind the skin of what it takes to make agile work.
In keeping with this theme, I'm delighted to announce that I will be doing one of the keynote presentations, entitled 'IPC Media - The Naked Truth'.
In case you haven't heard of IPC, it's one of the UK’s largest publishers of consumer magazines and websites, including many iconic brands such as NME, Nuts, Loaded, MouseBreaker, Good To Know, Now, Look, Marie Claire, In Style, Ideal Home, Living Etc, Trusted Reviews, Country Life and many more!
I am currently Web Technology Director at IPC, responsible for web technology across all brands.
IPC is a large organisation, with a lot of business stakeholders and a lot of web sites. Before implementing agile methods, this presented some really big challenges for the centralised digital division, trying to manage requests from many different business units, all with their own priorities!
The introduction of agile methods across all of IPC’s development teams has transformed the way the digital division works, aligning development teams with business units, managing priorities and expectations, speeding up delivery and building a reputation for delivering on its commitments, driving growth, and perhaps above all resulting in much stronger relationships between business and technology teams. Agile methods have really helped IPC Media to transform its digital operation.
Of course there is always room for improvement and a lot of lessons have been learned along the way! My keynote presentation will take a close look behind the scenes, revealing what life was like before and after agile, how the transformation was achieved, and highlighting some of the difficulties that had to be overcome to succeed.
There are also lots of other presentation tracks at the conference, ensuring that there's something of interest for everyone!
In one of these tracks, I'm also going to be presenting 10 Key Principles of Agile Software Development. This session aims to be a useful introduction for people relatively new to agile or wanting to cement their understanding of the key principles underlying all agile methodologies.
Why not come along? If my bit doesn't suit you, there should be lots of interesting people to learn from...
Kelly.
Agile Scrum, Or Not-So-Agile Scrum?
Scrum is the form of agile software development that has helped me the most.
It has helped me to transform the performance of the web development groups that I've led at both my current company and at my last one.
But, sometimes, I do wonder if Scrum is really agile enough?
There are quite a few regular meetings in Scrum. For short Sprints, this can be quite a big overhead. For me, that's where I can see why the Lean methodology appeals, especially to developers.
But there is also value in these meetings. So I thought I'd take a look at each Scrum meeting in turn, and assess whether or not their value really outweighs the effort?
First, there is Sprint Planning.
Sprint Planning happens before every Sprint. In our case, that's generally every two or three weeks. In Scrum, this meeting is split into two parts...
The first part is to discuss the requirements for all the User Stories intended for the Sprint as a team and give everyone on the team the chance to understand what is required. Questions are asked, and hopefully answered, that give people useful insight into how each User Story will be designed. Ambiguity is reduced and the team, hopefully, gains a common understanding of the User Stories and the requirements for the next Sprint. The collective experience of the team means that everyone gets the chance to input and the quality and appropriateness of the solution is potentially improved as a result. For a 2 week Sprint, this part of Sprint Planning generally takes about 2 hours, maybe less if the requirements for the relevant User Stories are well understood or well prepared beforehand.
Without this meeting, this discussion can still happen ad-hoc as and when someone picks up a User Story to develop. However, the chances are that the discussion will then occur with just the Product Owner, or perhaps one or two user representatives. It will be less onerous than having the whole team involved, that's for sure, but it won't benefit from the wisdom of crowds that you get from the group approach to Sprint Planning. The other thing about this ad-hoc approach is that it's more onerous for the Product Owner. They would need to be available most of every day and at the beck and call of the development team. If your Product Owner is not full-time and sitting with the development team, Sprint Planning is a useful way to ensure sufficient access to their time, and it's a useful way to pre-plan this regular event in everyone's diaries.
Weighing all of this up, I personally believe Sprint Planning is costly (in terms of time) but really worthwhile.
The second part of Sprint Planning can happen immediately after the first part, although some teams leave a day or so's gap between the two meetings, in order to clarify any outstanding questions before going to the next stage. The purpose of this second part of Sprint Planning is to plan the Sprint in detail.
The idea is that the team works together to break down all the User Stories into tasks, and estimate each task in hours. The team then plans their capacity for the next Sprint and decides collectively how much to commit to in the Sprint.
Personally I think it is useful to think about the tasks for larger User Stories, but unnecessary to do this for the smaller or simpler ones. Although Scrum suggests estimating all of the tasks in hours and going through this detailed planning process, personally I think this has some negative effects...
Obviously it can potentially take quite a long time, and with the whole team involved, that makes it an expensive meeting. But I also think - ironically - it can really hinder a team's ability to deliver on time. There are two reasons for this. Firstly, the team only estimates the tasks it can identify. They don't estimate the tasks they haven't identified. Inevitably there are some. Secondly, we all know by now that most developers are hopeless at estimating. Inevitably it their estimates will be wrong.
If you're on a large project, you may have already estimated all the User Stories on the Product Backlog in Points, in order to get an idea of how big the overall project is. If so, I personally think it's much more accurate for the team to commit to how many points they think they can deliver in the Sprint, and stick with that instead of estimating tasks in hours and trying to plan them in detail. In my experience, once a team's Velocity (the number of points delivered in a Sprint) has stabilised, this is a much more accurate way to gauge what a team can deliver in a Sprint, and it takes less time to do. For more information on this, see my post The Secret To Delivering On Time.
If the User Stories being discussed in the first part of Sprint Planning have not yet been estimated in points, I would suggest the team voting on the size of each User Story once its requirements have been discussed. Planning Poker is a great technique for doing this.
So, in summary, my personal view of Sprint Planning is this: It is worthwhile to discuss the requirements for the intended User Stories for the next Sprint as a team. It is worthwhile to estimate the User Stories in points, either when they go onto the backlog, or using Planning Poker to estimate them as a team in Sprint Planning. It is worthwhile for the team to make a collective decision about the amount of points they are able to commit to for the next Sprint, based on their experience of their past Velocity. Whereas breaking every single story into tasks, aiming to identify every task, estimating each task in hours, working out the precise capacity of the team for the next Sprint, and committing based on that, is not necessarily worthwhile. It takes a long time and can lead to less predictability about what can be delivered, meaning the team doesn't deliver on its commitments and people are disappointed.
During the Sprint, the only regular meeting in Scrum is the Daily Scrum itself.
This is where the whole team meets every day to answer three basic questions:
- What did you do yesterday?
- What are you going to do today?
- Is there anything blocking your progress?
This meeting should take between 5 and 15 minutes. No longer.
There is no doubt in my mind that the Daily Scrum is extremely worthwhile.
It keeps the whole team joined up and provides the Product Owner with clear visibility of progress and any issues affecting the team. This is one of the key ways that Scrum helps to ensure that development teams can keep stakeholder's expectations in line with their emerging reality. This is critically important. The definition of a successful project, at least in my mind, is one that meets or exceeds expectations. Therefore I would never personally suggest that a team does not have their Daily Scrum. It's a way to manage expectations on a very granular level, ensuring expectations and reality don't diverge along the way.
At the end of the Sprint, there are two more meetings: the Sprint Review and Sprint Retrospective. These are useful meetings, but because they're at the end of the Sprint, they coincide with the Sprint Planning meeting which is at the start of the next Sprint. Sometimes this can make it seem like meeting overload for about 1 day of the Sprint, which to be honest can be a bit wearing.
The purpose of the Sprint Review meeting is to invite all interested people to come and see what the team has achieved in the last Sprint. If this is kept brief and informal, I think it's really nice for the team to show what they've done. It's also really nice for people interested in the project that can't be involved all the time to see what's going on and have the chance to provide regular feedback. This is another important mechanism to manage expectations in small, bite-sized pieces, which I've already mentioned I think is critically important to the success of any project. It's also a useful motivator for the team to achieve good results in each Sprint, as there will be a Review meeting afterwards so it tends to keep the team more focused on delivery.
And last but not least, the Sprint Retrospective. The purpose of the Retrospective is to build continuous improvement into the regular Sprint cycles. Again, there are three key questions to be discussed by the team in the Sprint Retrospective after each and every Sprint:
- What went well?
- What didn't?
- What will the team do differently in the next Sprint?
Doing these Retrospectives so regularly throughout a project means that the learnings actually help to improve the team's Velocity throughout the project (and beyond). If it's kept simple, the things the team want to do differently in the next Sprint should be actionable and should actually make a difference to the efficiency and wellbeing of the team and the project. There's no question this is a meeting you can't afford to give up. There's just too much value in it.
However, because it coincides with so many other meetings at the start and end of each Sprint, it's important to keep it brief. For a 2 week Sprint, half an hour should be plenty of time to quickly brainstorm these three questions and action any changes in the next Sprint.
So, in summary - whilst on the face of it all these meetings don't seem very agile, I do believe the Scrum meetings do help the team to be agile throughout each Sprint. They help the team to gain a common understanding of what's required, improving the quality of the solution. They help the team to have a common understanding of progress and issues, improving the level of teamwork and visibility for the wider team. They help the team to see what's been achieved, improving the level of satisfaction and helping to manage expectations. And they help the team to learn from past issues and improve on them in the very near future.
My conclusion? Talking takes time. But it also adds value.
Kelly.
For more information on Scrum, see my series: How to implement Scrum in 10 easy steps!
Photo by incase
Agile Estimating in Scrum - Why Estimate Twice?
In my series of posts "How to Implement Scrum in 10 Easy Steps", I refer to two stages of estimating:Step 2 is how to estimate your Product Backlog.
Step 4 is estimating tasks in Sprint Planning.
Someone recently asked me a very good question - why estimate twice? I thought it would be worth addressing this question here...
The idea is that the first estimate, in points, is a high level estimate of everything on the Product Backlog.
At the time of estimating in points, the team has very little detail on what the requirements really are or what the feature has to do. They may be estimating from a simple heading or description.
This high level estimate helps with medium term planning (Release Planning) and helps the Product Owner to prioritise everything with some sense of how big the features are relative to each other.
Later, these points are used to calculate Velocity, which means the team get statistically better at predicting what they can achieve from very quick high-level estimates, which is is obviously very useful.
The second estimate is meant to be a detailed estimate for only those things that are included in the next Sprint.
Here, the team has the opportunity to potentially see some prior analysis of the requirements, to discuss the feature with the product owner and any other stakeholders, and to discuss the technical implications with the team.
At this stage, the team is in a much better position to break the feature down into tasks and estimate in hours.
At this stage, it is also possible to take account of the team's actual capacity at that time - i.e. how many team members available for the sprint, any other commitments, holidays, etc. With this information, the team should be able to plan the next Sprint reasonably accurately.
I have found that some teams like the second Sprint Planning estimates, and other teams can do without them.
The teams that do without still have the Sprint Planning meeting, which they still use it to discuss the requirements and technical design of the features in the next sprint, but they don't bother trying to break the features into tasks and estimate them in hours because they found invariably they were wrong anyway so it was a waste of everyone's time. Teams that are more accurate at estimating may be the ones that find it most useful for planning.
The teams that drop the hours estimates rely entirely on their historic Velocity (in points) to decide how much to commit to in each sprint, so they let the statistics take care of it.
If they have a lot of absence, or a team member missing, for any one Sprint, they simply commit to a slightly lower Velocity.
Personally I favour this approach. It's nice and simple and in my experience the statistical approach to estimating is just as accurate as the analytical approach, if not more so. The trouble with estimating analytically is that you only estimate what you can think of, and inevitably you can't really think of everything. Even if you think you can.
One thing I can say for sure, though, is that the Sprint Planning meeting is still exceptionally useful for the team to discuss the next Sprint together, whether you break down the tasks and estimate them or not.
In case you haven't discovered it, I've written quite a lot about agile estimating on my blog. You can see all of my posts on the topic here - Agile Estimating.
Kelly.
Photo by jronaldlee
