Benefits of Agile and Scrum? (a guest post by Faisal Mahmood)

I am publishing a guest post for the first time and I am happy that this post is by Faisal Mahmood – fellow Agile trainer and coach. I hope you enjoy reading it.

Curious about benefits of Agile and Scrum?

Agile and Scrum enable you to

1. Respond to market changes while controlling risk

2. Increase ROI (return on investment)

3. Continuously improve your process

4. Increase quality of your products

5. Work at a sustainable pace

Respond to market changes while controlling risk

Ignoring Agility is not an option any more in the fast moving markets of today.

Change is one of the biggest project killers. With Scrum and Agile Scrum, you do not need to be afraid of the change. Agile equips you to respond to rapid changes in the marketplace while controlling risk. It is of no use to respond to changes and become bankrupt. Scrum and Agile focus on emergent planning which empowers rapid response to changes while helping you control risks.

Increase ROI (return on investment)

60% of the features in the products never or rarely get used, but still, we keep building and maintaining products and features. This, of course, lowers our ROI. Scrum and Agile help you focus on the highest value features in your products and features. With focus on value, increase in productivity and quality, Scrum and Agile set you on a journey to higher returns.

Continuously improve your process

Scrum and Agile emphasize continuous improvement. Scrum has built in mechanism to help you see the issues that are holding you and your organization back and enable you to leverage collective intelligence of your team to devise solutions to these issues.

Increase quality of your products

Did you know that more than 50% of IT budgets are spent on maintenance? This is caused by low quality products which become painful to maintain. Scrum and Agile help you build quality right in your development process. Quality becomes part of the whole process.

Work at a sustainable pace

Agile and Scrum Teams are empowered yet accountable for delivery. They self-organize to deliver valuable increments of products at a sustainable pace.

Faisal Mahmood is the author of the book Agile Adoption Mistakes You Must Avoid. Faisal is a Certified Professional Scrum Trainer based in London, UK.

Agile note taking – Introducing “The Note Card”

You know index cards? I started using them for Agile note taking.

There’s several reasons why I dislike notepads:

• they’re too big to carry
• they have many pages
• I always forget them
• I spend ages trying to find out my notes
• they have brands and some are shinier than other

I have been experimenting using index cards for taking notes for a while and I have recently “formalised” my method by combining short notes with priority highlighting and action indication.

There’s several reasons why I like Agile note taking

• index cards are light & small
• the size forces me to be concise with my notes
• the size forces me to select what to record
• I can carry the card with me and throw it away once all actions are done
• usually nobody else is using the method

It really is very simple – have a look at the picture (notes are blurred to hide client related information) :

You can build whatever shapes you like (I prefer square like shapes) and write your notes the way you prefer. I enjoy building a uneven brick-like wall by avoiding straight lines and using curves here and there. I then indicate actions by using the (A) sign, highlight the urgent & important things using orange and non urgent but important using green, whatever blocks are left uncoloured are just for information and that’s it.  The colours could be different of course as long as you know what is what which is why I sometimes add a little legend at the end.

As you can see Agile note taking is cool – and you can try it anytime you feel like it, after all you only need an index card and a pen.

Kiva - an awesome way to help people

Thanks to Jurgen Appelo's tweet and blog post today I discovered Kiva 

I signed up and already made a couple of loans.

What an awesome way to help people who want to make a difference. And loans can be as small as $25 - this is about £16 today.

I agree with Jurgen - this is much better than donations.
Donations are probably still the only way to raise money for certain causes but Kiva feels like the right way.

The concept seems to me very similar to Dr Yunus's Grameen bank who clearly has found a great solution for boosting people who want to work and just need a little bit of help.

And this is the key for me.. So if you would like to start by lending a free $25 then use this link  and start helping people who have found the drive to try and make a difference.

The ‘Non-Plamen’ Book

Last week I travelled to Vienna to participate in Jürgen Appello’s Management 3.0 training. I liked it so much that I decided to enrol as licensed trainer for this course (which is not the topic of this post but I felt it is relevant)

I also thought that the Roving Coffee idea was brilliant so I joined the evening meet up at Coffee Day in Vienna. Now Coffee Day is an Indian company and I have actually visited the first CoffeeDay shop in Bangalore so I felt it is a nice coincidence. Couldn’t taste the coffee there obviously as it was past 8pm when I arrived so I had beer instead (and it was good ).

My taxi driver completely messed up the destination address and the poor fellow didn’t speak a word of English so it was difficult to guide him with my superior orientation skills (those who know me well will recognise the irony). So I missed the beginning of the meeting and on my entry I was clearly expected to bring some ideas which I did although perhaps they were of the wrong kind. Anyway it was a lovely chat in which we decided that it is not a very good idea to start changing the world from Vienna mainly for historical reasons – something to do with WW1 I think although later on reading through wikipedia I realised that it was not a valid reason.  Having in mind that most of us were drinking beer I guess it was sort of OK.

Now about the title.. just before finishing the meeting Jurgen asked who wants to have a copy of his Management 3.0 book (he only had one copy). Everyone declared that they already have the book including myself so the first round wasn’t very successful. And then I had this great idea that if nobody wants the book then perhaps I can take it and give it to someone who is unlikely to buy it therefore doing my bit to change the world. Everyone thought it is a great idea so there it was - I had the book. Next thing though – Jurgen asks me – do you want me to sign it? Now here’s a game changer. That brings a bit of hesitation so I am saying – well if you sign it then it is more likely that I will keep it (which I do not want to do)… Jürgen repeats the question to which I suggest – fine, then write something that ensures the book cannot remain with me.. and here’s how the ‘Non-Plamen’ book is born!  See the picture below:

The text reads:

“This is a non-Plamen book. Only people not named Plamen may own it. If your name is Plamen you must get rid of this book in 3 days, or it will self destruct.”

Of course I had no intention of waiting for more than 3 days to see if the prophecy will be fulfilled. I got rid of the book before the 4th full day and I hope it will serve well its new owner!

And finally just to prove that this was all real and not made up – here’s all the participants in Roving Coffee in Vienna. Note that while we’re all smiling Jürgen is demonstrating that the camera of his phone isn’t very good!

The meeting without agenda

Many articles and books that discuss productivity of meetings suggest that a meeting should have both a goal and an agenda as a prerequisite for starting the meeting.

While I am perfectly happy with this rule and I am certain it applies to the majority of meetings I can argue that once in a while there're meetings/discussions for which figuring out a goal would be as good as starting the meeting and having an agenda is almost pointless as the initial agenda is unlikely to be followed once participants discover more about their goal.

For example - think about a meeting with another team to discuss integrating two products or components of a product. The goal could be - to agree on interface for this integration and the agenda could be
1. Introductions
2. Team A (frond end team) presents the information that they believe they need
3. Team B (back end team) evaluates the requirement and suggests a solution
4. Teams generate ideas and discuss options
5. Any actions are reviewed and owners assigned

Easy, right? It is even easier if it is a recurring meeting when the goal is usually well understood and you can refine the agenda to ensure current requirements are met.

Now consider the following scenario - a new requirement is introduced by the business which would mean changes across components and domains and would potentially affect a few or perhaps all teams. Team members voice concerns and suggest a meeting to decide how to proceed. There's numerous concerns  some very specific and some too vague.

When faced with similar scenario recently I have decided that the goal to "decide how to proceed" is too vague and I suspected there's several more specific goals that can be more useful but wasn't sure what they are and consulting almost 30 team members about that would in effect mean starting the meeting earlier (and probably making people unhappy that they are being interrupted). Due to my expectation to see many different goals I also thought the agenda will drastically change and depend on which goal is most important.
So I decided to start the meeting by inviting everyone to state their goal and recorded the goals on a white board. I then read all the goals and asked the team to indicate which 3 goals are the most important to them. Finally I counted the votes and identified the 3 goals with most votes. I then suggested that we should spend a fixed amount of time (e.g. 10 minutes) discussing the first goal. At this point I did not really have much of a plan rather than hoping that the team can generate it or else some obvious actions may come out of discussing the top 3 goals.
In this instance the team did have very good suggestions, with very little participation on my side generated the next points on the agenda and with some minimal time managing intervention we managed to complete the meeting on time, do a re-cap at the end that suggested almost 100% of the participants were satisfied with the result.

So here's in summary the approach for the meeting without agenda and vaguely stated goal:

0. Explain to the best of your knowledge why are you having the meeting and state the suggested time slot - e.g. 1hr
1. Explain why there is no goal and ask everyone (best to go around the circle) to state their goal for the meeting
2. Record all the goals on a white board (try grouping where necessary)
3. Read the goals so that everyone can hear them and allow some clarification questions where necessary
4. Ask the team to pick their top 3 goals
5. Count the votes and announce the first goal to discuss
6. Time box the discussion and let/ask the team to make suggestions of how to proceed

From here on the meeting may take different from from what you or the rest of the team expect.
Some tips that will help you:
7. Remember to time box any discussions and ensure they do not overrun
8. Ensure the group is happy with any statements made by individuals rather than changing direction every time a new suggestion is made
9. If the group is big or if people are interrupting each other and fail to progress because of that introduce a talking token (e.g. only the person holding the token can talk and if someone wants to talk should ask for the token)
10. Ensure the meeting ends on time unless everyone agrees to extend it (sometimes this might be more valuable than finishing on time)
11. Before the meeting ends ask for a re-cap so that everyone hears everyone else's position. This might indicate if another meeting like this is required or more specific actions have already been generated and the group is happy to close the discussion.
12. And finally remember that you own the process not the content - trying to participate will damage your ability to time manage, spot actions items or introduce new rules when necessary (e.g. the talking token)

Well I hope the suggestion could be useful if you face similar situations. Good luck :-)

Quick backlog estimation

One thing that's been really painful in my previous experience is overall backlog estimation. This is often asked for by the business owner as an impact assessment or to try and gain an understanding of roughly how long is a chunk of work going to take.

The issue is when the chunk of work is split into hundreds of smaller chunks of work each of them requiring a fair amount of analysis and design and perhaps UX, etc. in order for the estimate to have any reasonable meaning. Teams often aren't allowed this time while the need for sizing of the chunk of work still remains and could be important to the business.

Over the past few months we have used an approach to fast backlog estimation which combined with follow up prioritization session (I will post about this in another blog post) has resulted in acceptable outcome for both sides. In order for this to work  it is useful if your team has achieved good level of common understanding about estimation of requirements and your backlog should contain a list of user stories and (almost unavoidably a list of epics).

Start with User Stories

Prepare by printing all your user stories (I'd print them all and not use any existing index cards) and have a big table available for the session. Ideally ask 2 dev pairs (or may be 3 devs and a QA) to join you. Separate user stories from epics and work with the user stories first. Separate the cards into 2 piles and give each pair of team members one pile. Ask each pair to work in one half of the table so they don't mix cards (for now). Also ask them to put the user stories in groups by size - e.g. in the middle of the table user stories that seem to be about the average size of a typical story (Group A) , at the top user stories that seem much bigger than average (e.g. 2x or 3x) (Group B) and at the bottom user stories that seem very simple (e.g. 1/2 or 1/3 the average) (Group C) . After this phase is done ask the pairs to switch sides of the table and review what the other pair has done and mark any cards that they may not agree with the suggested sizing for discussion. Have the discussions and move the cards as appropriate if that's what team members agree. You can also have a 4th group of cards (Group D) for stories that have so many unknowns that it seems impossible to put into any of the other groups. Once this phase is done make sure to carefully collect your cards in groups so you can update them later on.

Now the epics

Following a similar approach hand each pair about half of your epic cards and ask them to group them in the following groups. For example in the middle of the table - those for which is  relatively clear what needs doing but it just seems like a lot to do (Group E) , those that seem relatively small at the bottom of the table (Group F) and those that seem fairly unclear or there are lots of unknowns put at the top (Group G). Again ask the two pairs to work in separate half of the tables and then swap to review their groupings. Once this is done thank the team members for their participation and with all collected cards proceed with updating your actual cards in excel or the electronic tool that you're using.

This should take you between 25 and 40 minutes depending on your backlog size. We have consistently achieved below 30 minutes with backlogs of around 80-150 items.

Getting to numbers

Now this will depend on your specific team estimates. I'll take an example where the average size of a story for you might be 5. Note - any stories estimated by the whole team in your usual estimation workshops leave as they are - you can use them to calculate your story average. For any stories without estimates you can do the following: Assign this to group A cards, to group B cards assign 3 times your average size - which would be 15 or perhaps 13 if you're using Fibonacci numbers. To group C stories assign estimate of 2. To Group D items assign 20s and  give to your BA/PO for further analysis - somehow indicate this in your electronic tool. There's two approaches you may want to use for the epics.  Either look at them as gaps of missing stories and ask your BA/PO to estimate how many stories approximately (and as a range) s/he thinks they may contain and use the average story size - e.g. Gap A is likely to produce 5-8 stories so I'd use the higher estimate of 8 and multiply it by my average of 5 which means that Gap A will have size of 40 for the time being.
Or if your BA/PO is not comfortable to do this for now use similar approach to stories e.g. - to Group E assign 3 times the group B estimate - e.g. 40, to group F assign the group B estimate - e.g. 13 and to group F items give something like 2x your group E estimate - e.g. 80 or 100.

Backlog size

Now once you've done all the updating your total backlog size will probably look enormous. Obviously the more epics you have the bigger number you'll get. Explain to your BA/PO that the epics need clarifications and that you'd need these resolved, questions answered and sizes refined before having a meaningful backlog size. Your BA is likely to start analyzing all over the place so why not start with these big items alongside any risky items s/he might be looking at. You could also review the remaining unanswered questions and gaps on a weekly basis reiterating that the sooner you refine those estimates the sooner you can get to a realistic size.


Interesting enough having epics in the backlog has not stopped us doing prioritization sessions with business owners - I will explain how in another blog post.

Once you agree that your backlog seems to contain mostly stuff with known size then you can follow standard burn down/up practices to produce that much desired date/range. I'd also monitor historically what is the growth of the size of a backlog and apply that as a buffer because new stories will get produced. Ideally you'd want to have this growth historic figure based on a full release cycle.

So this one has already  become bigger than I was hoping it will be. I hope it is useful and makes sense. I will try to take a picture next time we do this and attach it here. All feedback is welcome ;)

One week is just right

This goal of this post is to outline some good reasons why one week iterations are a very good idea for most software development teams.
The suggestions and conclusions below are based on my experience with one week iterations across 3 teams on a major e-commerce project.
Before seeing one week iterations in action I believed they could be too stressful and with very little time to prepare requirements or even complete something useful and potentially end up with nothing to demo most of the weeks. I have since changed my opinion based on almost 50 iterations of evidence so let's start with the reasons

1. It is tough! What I thought before turned out to be true! There are so many things that need to happen for a week and yes it is tough. It is tough for the analysts to prepare requirements, meet with QA and refine them, meet with devs and refine them, get answers and slice and descope as necessary. It is tough for the devs to ensure requirements are small enough to develop and meaningful enough to present, reject requirements that aren't ready, estimate and tech design and implement those that are. It is tough for the QAs to participate in acceptance test specification for new requirements, acceptance test writing for those in progress, functional and journey tests, exploration tests and demo preparations. You get it I believe. Yet even though it is tough it is also very useful that it is tough because it is a built-in pressure that ensures people switch on to disciplined mode because to get through all these you have to be disciplined. So reason number one is that the busy schedule increases discipline and discipline is the best friend of competence.

2. There is stuff to demo! - with over 50 iterations of evidence I am confident one week iterations will not impact teams ability to show progress. Quite the opposite, the ability to show something that isn't just working but actually in most cases ready to go into production is the best way to win the customer over and over again. You could say in most companies the stakeholders would be amazed if you are able to deliver quality meaningful features every week.

3. You really are more agile/flexible. Actually seeing the impact of one week iterations I am starting to think that anything more than 2 really isn't much help in terms of flexibility. Shorter cycles let you fail faster and improve faster. They also allow the business to adapt faster and significantly reduce any change concerns. Shorter cycles also enforce good engineering practices like emerging design and architecture, continuous integration and deployment, true shared code ownership and refactoring.

4. These guys are great! Even though I already touched on credibility in point 2 I think it deserves a separate section. Your ability to deliver every week will impress people, especially if you're the first team in the organisation to do such short cycles. Along with your CI tools and your ability to deploy anytime and I am sure these will prompt even more amazing practices and tools it is very likely that you soon will become centre of attention and people would want to associate themselves with your team and even work for you. Granted this may happen without one week iterations but I believe they improve your chances.

5. It is all or nothing. If you've ever heard a business owner saying "they're all must haves really" then you know what I mean. What one week iterations combine well is positive feeling about delivering all the time and a shorter release planning cycle. And in case you're wondering yes I do mean looking at the release plan with the business owner every week or as often as possible but never more than 2 weeks between the sessions. The combination of high business confidence in your ability to deliver with the regular realisation what is possible with the current capacity and what not will virtually ensure the business owner's buy in into fixed date/flexible scope idea. (I would not really want to go for fixed scope/flexible date but that is for another article).  And that is one of the most important hurdles to making your release successful simply gone.

So in conclusion - I believe one week iterations are just right. Of course based on the environments that I've seen but also based on feedback from 20+ colleagues about the environments that they've seen.
So I'd say it is a pretty good bet that it would help you if you're thinking about doing shorter cycles. And I hope you won't forget to have fun ;)

Futurespective (the way we do it)

Furturespective (also Future-spective) is an approach to run retrospectives or improvement workshops which attempts to drive out possible improvement opportunities (usually to process but can be others) by shifting the group's focus into the future and then looking back from there. It is described well by Anders Laestadius here however this is not exactly the way we do it in my current team. So I decided to write up a summary of the "Furturespective the way we do it":

The agenda is usually something like this :

Check-in - Sometimes, especially if you do it for the first time, the check-in can be your explanation of the concept of the Futurespective which is usually engaging enough to get people's attention

Successful end: Explain that you're now at the end of the project/delivery/release and it is a success so you ask the team to brainstorm the reasons why they аre successful.

When step 2 is over (say 5 minutes) ask everyone to post their items on the board and explain them (and group as much as possible)

Unsuccessful end: Now explain a second scenario - the project is a failure and ask the team to list possible reasons why this might have happened.

Like in step 3 after short brainstorming ask the team to post and explain the generated ideas/reasons.

Now ask the team to vote e.g. 3 votes each or choose more appropriate number based on team size.  A variations can be 2 votes per positive item and 3 for negative.

Count the votes and discuss the top 2-3 items (depending on time restrictions)

Discuss the top voted items and try to generate follow up sessions or actions.

Check-out

Hope this is useful. Thanks to @alfie_thomas99 for this version of the futurespective.

So what's new in LeaveWizard land

Together with Rich Allen I have been working on this great app called LeaveWizard for over 2 years now.. And I've never blogged anything about LeaveWizard and it's a shame because I am so passionate about it.. well as you may guess there was a reason not to blog but that reason is now a distant and insignificant past so here comes my first post on LeaveWizard.

What is it?

LeaveWizard is an online based application that helps you organize and manage absence and events for your teams. We have taken an approach that gives you simplicity if you choose not to modify the default options and it also has built in flexibility to support fully customiseable event types including time off in lieu, work patterns that lets you design custom shifts, leave restriction at different levels and custom groups. It even supports simple room booking and the list of features is growing every week.

Why did we start it?

We started LeaveWizard because of a common 'leave management' problem we both experienced. We also started it with a desire to build a great application that our customers love to use. The core values that help us progress are simplicity, user feedback and built in quality.

What's new in LeaveWizard land

Now on to the point of this post. Every time we release new features we make them visible through a blog post in our LeaveWizard blog. We also add to our collection of extended help articles to help customers get started with the new features.

Over the past 6 months we have added some really cool features like accrued allowance, new UI which follows an ultra simple pattern to help customers get up to speed and get the job done quickly, events like overtime that can turn into additional allowance, calculation of the bradford factor which is a funny number to have available to you (if you wanted to go that route), support for event type that have allowance in hours and many small enhancements like controlling event types that get published in calendars, visibility of event type allowance and event details, hiding certain users from lists and charts and configuring various options for customers so they can make the most of the application.

One thing we love is to hear feedback and ideas from our customers, which is why we regularly monitor and pick ideas from our feedback forum.

So now I have blogged about it I can start looking at the stuff that's next on our list so I have more reasons to blog about the new cool features next month.

A year of new beginning, excitement and tons of learning

My year runs to end of August. The time I spend back in my own Bulgaria naturally marks the end and the beginning. And it feels like this is a much better point in time than the one suggested by the calendar.

So here it is again - it is that time of the year. I am off tomorrow and have 10 days to go through my "rebirth" once more. And before I go there's a few things I shall write down to remind me of 2011.

"What a year" are probably the only known 3 words that can fully describe it. While 2010 was a(nother?) year of frustration, ridiculous events at work, lots of sadness to go through with the only real highlight being the visit to India, 2011 brought the new beginning I was so long preparing and longing for, two visits to dream destinations and most important of all - finally - a work place where I no longer have to deal with any of the weirdness and frustration that were built into my days before. LeaveWizard also made a significant step to becoming a success and as time goes by working on the product continues to be a privilege and pleasure.

The significance of the events in 2011 is so immense for me that words cannot describe it well enough. If I achieve the same in the next twelve months I'd be extremely happy. I hope at the very least I do not miss many opportunities to learn and I also hope that together with this amazing team we can build the right product right (or at least get as close to that as possible).

So with that I am off to get a few days break, some sunshine and generally restart. Ta-da.