Want to be an Independent Scrum Coach? Leverage the Community

Fredi Schmidli talks at Scrum Breakfast about
Outsourcing and Scrum

As an employee wanting to become a Scrum Consultant, I knew Scrum, but didn’t have any customers. There was no established market for Scrum coaches nor were there any big companies doing Scrum projects. I couldn’t sell Scrum in the traditional sense, so I needed to help potential customers discover Scrum and make sure that they would find me when they got serious about doing Scrum. My solution was to build a Scrum community and this is how I did it.

If you are wondering how to become an independent Scrum coach, I would suggest starting or joining a local Scrum community. You can help make the market more interested in your chosen field and therefore in you. You can find other people who share your vision. You can become a magnet for requests for information. You can create an environment where you can meet new customers. You can do all this without a marketing department.

Inspiration from Open Source

Back in 2000, I joined the board of the Swiss Open System User Group (“/ch/open”), an established but at the time “dusty” user group, whose members were drifting away from the organization. At the same time, the Linux User Group Switzerland was an energetic and dynamic club, thanks largely to their biweekly “LUGS-Meets”: an interesting talk and quality community time. At /ch/open, we adapted that concept for our members, and the
Open Business Lunch was born. And yes, it helped revitalize the organization.

The consultant-evangelist’s challenge: finding customers

Scroll forward to 2007 and I am facing a similar problem. If the company is not already convinced to use Scrum, the sales cycle is too long. A man does not live on marketing alone, so I had to find companies that had already decided they wanted to do Scrum, or better yet, these companies had to find me.

What would it mean if there was an active Scrum community in my area? For one, potential customers and partners could find me (and other Scrum Gurus) easily. Other evangelists and early adopters could help carry the message to their companies. And a regular event would be a pressure-free opportunity to network with potential customers and partners.

How I started the community

I started out blogging to establish a relationship between myself and the community. My goal was to write frequently about interesting, Scrum related topics. If they can’t find you in Google, you don’t exist. If you write often, Google will make it easy for people to find you. The blog is where customers will find you when they are researching a topic. Even offline, you can refer customers to your blog (and demonstrate your expertise) when they are confronted with a problem.

A regular event is an opportunity for a conversation.

Then I started to hold a regular event, the Scrum Breakfast for potential members and customers.

“The Scrum Breakfast is monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO’s, executive and operational project managers. The program starts with a short presentation about an interesting topic around Scrum. A moderated discussion among the participants follows the talk to encourage an exchange of know-how and experience.”

The time slot competition at breakfast was the lowest, so that determined the time of the event. I was able to publicize the event in existing user forums (like
deutschescrum), which would not have been true of a commercially oriented event. I gave the first talks myself, but after a few events, people started responding to the call for participation.

Reach out to other organizations

At the same time, I reached out to other organizations, like /ch/open, Jugs, Reto Hartinger’s Internet Briefing, offered to give talks (for free, or course) about Scrum. And at the end of each meeting, I invited people to join us at the next Scrum Breakfast.

I sent out a monthly newsletter to anybody who was interested in the event. This announced the coming event and was also an opportunity to highlight recent blog articles or announce upcoming courses. I did have to strike a balance between Scrum Breakfast and “private” announcements. The SPAM filter is only a button away.

Expanding the community

After a few Breakfasts, a colleague from the SwissICT, Switzerland’s largest IT association, suggested that a more formal Scrum user group would be the logical next step. Anchoring Scrum into the broader IT community would help market acceptance. He put me in touch with Reto Maduz, a Business Unit Manager at a leading Swiss engineering company which had also started publicizing Scrum and Agile Methods, and together we founded the Lean Agile Scrum Group of the SwissICT. The Scrum Breakfast became an official event of the L-A-S-Group.

My colleague was right. The impact of associating the Scrum Breakfast with a larger organization has been dramatic. The latest Breakfast filled up two weeks before the registration deadline. A core group of 10 people is now working on everything from a website to organizing events and writing articles for the press. We have received our first requests from other organizations for speakers and articles. And customers have reacted positively knowing that their suppliers are active in the group.

How long did it take?

In October, 2007, I held the first Scrum Breakfast. Shortly thereafter, it was clear that my destiny was to become an independent consultant. At that point, I started writing my own blog. In April, I was independent with my first customer (but not one I found through the community). In June, my work starting bearing fruit – Artem’s inquiry if I would write for ASD was one of the first requests coming out of my blogging. By October, I had found my first project through the community.

As I write this in January 2009, I think I have found a marketing partner for my Scrum courses. At least one person is considering a job offer he found through the community and two independent consultants are starting to reach out to potential customers through the community. So 18 months later, the community is working for me and for its members.

Organizing an Agile gathering in 5 simple steps

Last week a second Agile Dinner was held in Tampere. It eventually made me find time to publish photos and my lighting talk presentation from the first dinner that was held in Tampere on December 4 2008 and had a great success.

To make this post at least a bit useful to the people who haven’t been present on the dinner, let me share with you how easy it is to get an Agile community started. The plan consists of five steps:

  1. Get to know the local agile mailing list. It’s ok if there isn’t too much traffic.
  2. Prepare a lighting talk to serve as a discussion starter. 5 minutes max
  3. Create a wiki page for self registration couple of weeks in advance. Post announcement on the mailing list. Tentatively book a room in the local beer restaurant or bar (just for an hour or two)
  4. A week later after seeing how many people register, book tables in the bar
  5. Come, talk and drink.Or eat.

In our case the whole process tool less than a month from the original idea posted by yours truly in the beginning of November, to the finding of a courageous organizer Antti Tarvainen in mid-November to the actual dinner  in the beginning of December.

If you ever took part in organizing similar lightweight gatherings, please, share your experience in the comments.

Materials from the Dinner:

  • Some photos (see more on flickr)
    IMG_0333 IMG_0341
  • Presentation from my lighting talk on the misapplied Scrum pattern inspired by the Decline and Fall of Agile by James Shore

My First Agile Project: Go-Live – The Final Frontier

Picture courtesy of papalars. on flickr

We did it! The project I’ve been talking about all this time has finally gone live and is now being used in production. Pretty much everything worked fine on launch day as well, which was nice. 🙂 In this installment of My First Agile Project, I’ll talk about the last week of the project and where we go from here.

The last weeks of any project are pretty hectic and this was no exception. Our last week was a weird one though as we were theoretically in a code freeze (more on that below), and we still had to finish final testing, and we had to be done by Thursday so our database admins could start the data conversion first thing Friday morning. We all pretty much ran around like chickens with our heads cut off all week but once Friday came a weird sense of calm had settled over most of us (it might have been a fog of fatigue or brain tiredness, it was hard to tell). The DBAs had run through the conversion process 29 previous times so while they were working, it wasn’t some new process. The conversion process ran like clockwork, even finishing a few hours earlier than projected, and on Sunday we began the final Go-Live steps.

Sunday morning when I got to work, there were still some final conversion processes going on so a couple of us got to the important work of setting up a big screen TV and some seating to watch the NFL playoff games that were going on later. Most of us didn’t end up watching much of the games but the Go-Live Lounge, as we called it, was a fun place to have a break. Also, Go Cardinals!

Semi-Frozen Code
During the final week, we had determined that there were a couple of smallish fixes that we would need to put in before doing any real work on the system. Of course we all wish these things would have been found earlier but these things happen. Because we were so paranoid about the data conversion process, we had done a code freeze and decided that we would do the conversion using the same code that had been used the week before. This meant that we would do the conversion on the same code, then update the code to include the fixes, then bring the system online. The fixes were important enough and small enough that we all decided it was okay. If something broke, we had backups anyway and could roll-back. We finished the conversion process early on Sunday, did the update, and brought the system online in the afternoon for “sanity testing”, just to make sure everything was working.

Sunday
Once the first testing was done, the team started putting real work into the system from the past days where everything had been down. This part took a lot of coordination. Since this is a billing system, we need to make sure people’s payments went in and nobody got into any trouble with money not being in their account because we had been down. We need to post payments, make sure all the money was distributed and invoices were generated so it would all look seamless. It’s a credit to everybody involved that I don’t think anything noticeably wrong went out to customers.

I ended up being at work 11 hours on Sunday and others were there longer than that. I shudder to think how little sleep our DBAs were running on. Luckily our management had made a big trip to a nearby warehouse grocery store to stock up on a table full of bad-for-our-health but delicious goodies to help keep our batteries charged.

Monday
We were all back at work Monday morning as well, to make sure everything looked okay and to start our list of things to fix. We put a couple of minor fixes in Monday afternoon but nothing too ugly. I think the worst thing we forgot was that I left the wrong starting check number hardcoded into my code so the first batch of checks were numbered incorrectly. Luckily, the fix for that ended up being a better solution than we had originally written so it worked out alright. Monday evening our Product Owner made the final decision to go ahead with the new system and not roll back to legacy. In celebration a coworker played the Peanut Butter Jelly Time song over our building PA system (an inside joke on the team), without knowing that our CEO and Senior VP were still in the building. They know us though so I don’t think it phased them.

Tuesday
Tuesday was perhaps the most nerve-wracking day of all, being the first day people would be back at work and using the system for real. It doesn’t matter how much you test or how comfortable you are with a system, the day people start really banging on it and seeing your stuff in action is fairly frightening. I found an issue or two with some of my stuff that hadn’t been exercised enough but overall nobody found anything especially ugly.

The Go-Live Celebration Cake – The text says “Because going live sometimes requires coming up with new ideas so rad you have to create new words just to be able to think of them” Thanks to Amnon, Tom, and Grace!

Thursday
Thursday was the first day where we went back to Scrum for real. We did a 15 minute stand-up meeting in the morning and had our first Sprint Planning meeting that afternoon. Boy, it felt good to be back to planning and sprinting for sure. We’re going to do 1 week sprints for the next couple of weeks to take of some things we pushed back to after Go-Live. We had a fixed deployment night of Wednesday so anything we want to get in has to be done and tested by then. Because of this I don’t think 1 week sprints will work for us long-term. By the time we do a planning meeting, work, and test our changes we won’t be able to get a lot done in a week. Our plan is to move to 2 week sprints in a few weeks so we’ll be able to compare the two approaches.

The Future
Our plans from here on out are far from decided. The team knows what we would like to do but we’ll have to see how much influence we have over things in the coming weeks. What we hope to do is do our 1 week sprints on this project only for a few weeks. Then we’ll move to 2 week sprints and start moving in tasks from our other long-neglected projects into the plan. The big benefit of this plan that I’ve tried to explain to management is that we can work on multiple things at once, or put all of our effort toward one thing. We’ve got maintenance tasks to do, new stuff to build, and a big upgrade coming before too long. A multi-project Scrum plan seems like it’ll work very well. But we have to deal with the fact that we may very well have lost enough credibility with the exploded timeline of this project that our options are limited. I hope not though and the team and I will sure fight for our vision.

Now that this project is over, I’m going to change the focus of this column as of this installment. I think this is going to be the last My First Agile Project. Next week I’ll return with a new name (suggestions welcome) and the column will be following my team as we navigate the changes to our status quo from the past year and a half. I hope to document the plan as I described above, as we move to multiple projects, but whatever happens you’ll hear about it if you stay with me.

Thanks for reading My First Agile Project. If you missed any of the past posts, there’s a handy table of contents to the whole series below. I’d love to hear what you think in the comments below. One of the best things about writing this series is the great comments people have made. Thanks again and Stay Tuned next week. Same Agile Time, Same Agile Channel!

My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool – VersionOne
Part 10: 5 Important Issues For Teams
Part 11: A Tale of Two Dark Clouds
Part 12: The Good, The Bad, and The Ugly – Our Retrospectives
Part 13: Reflecting on The Decline of Agile
Part 14: Did We Need A Coach? Does Anyone?
Series Review: So It’s Come To This – The Year In Review
Part 15: The Last Mile
Part 16: Go-Live – The Final Frontier

A Simple Scrum Sprint Review

Picture courtesy of cole24@Flickr

At the end of the sprint, the Product Owner, Team
and Scrum
Master meet to review the progress of the sprint. The product owner has
to
evaluate the state of the project so s/he can decide what to do next.
How does
the Product Owner ensure that s/he gets a complete and correct
understanding
about the state of the project, including all inconvenient truths? Here
is a
simple agenda/meeting template to follow, to make sure all the bases
are
covered.

Last week, I introduced that concept of a Sprint
Contract
to
define the parameters of the sprint. The factors Scope, Quality, Time
and Cost
will be familiar to any project manager. Scope is defined by the
stories and in
particular their size. Quality is defined primarily by the definition
of done.
Time is fixed by the sprint duration. An upper limit on the costs is
set by the
team size * sprint duration, after adjusting for absences and other
tasks.

A simple sprint review needs to

  1. Confirm that the team has delivered on its commitments
  2. Confirm that the overall project is on track
  3. Examine the functionality which has been delivered.

Confirm that the team has delivered on its commitments

The Scrum Master should take a few minutes to
review and
summarize the agreement between product owner and team. How many
stories? How
many story points? What is the definition of done? How much effort did
the team
plan to invest?

Next the Scrum Master should present a summary of
what the team
actually accomplished. How many stories achieved done? How many story
points?
Did the team invest more, less or the same effort as planned? If there
were any
important differences, now is the time to make them visible.

Confirm that the overall project is on track

The Release Burn Down chart is the primary tool
for
measuring progress and scope of the project. Scope, progress and
estimated
completion date are all clearly presented in one easy to interpret
chart.
Everyone in the project should see the update release burn down chart
after
each sprint. It’s even better to keep it posted on the wall.

Is this enough? Beyond the basic burn down chart,
it might
useful to keep an eye on the other parameters of the project, i.e.
quality and
cost.

Monitoring quality builds confidence in the
product and
keeps your technical debt under scrutiny. The number of unit tests and
acceptance tests defined and passed should increase every sprint.
Insufficient
tests are warnings that technical debt is accumulating or that
requirements
could change suddenly as the project nears completion. A rising number
of open
bugs may be a sign that the quality is not sufficient. Your next
retrospective
would be a good to time ask yourselves how to produce fewer bugs.

I think the main reason for monitoring work
invested is to
make sure that your teams efforts are not being diverted from the project.
Monitoring
budget in actual money will keep your top management happy and make
your
Product Owner’s life easier. Budget can be tracked with a burn down
chart, just
like scope, and the budget divided by burn-rate should be sufficient to
cover
the remaining sprints.

Examine the functionality which has been delivered

Your team is only allowed to demonstrate finished
functionality, i.e. meets the definition of done. My experience has
been that trying
to demo unfinished functionality causes trouble — things which haven’t
been
fully tested often break. Everyone should get a chance to talk, so each
developer should demonstrate the functionality s/he was primarily
responsible
for.

As a product owner, you should ask questions and
explore.
This is a demo of product which your users will use, not a tour through
the
mine field. So everything you see should work or fail gracefully.

Once you’ve seen everything that is done, you can
discuss
briefly anything which was not successfully delivered. Why wasn’t it
delivered?
What needs to be different, so that it can be completed in a future
sprint? Or
do you need to rethink?

The Simple Scrum Sprint Review Meeting

Here is a sample agenda for the meeting, with
timings for a
2 week sprint.

Present: Product Owner, Implementation Team, Scrum
Master
Moderation: Scrum-Master
Duration: 1 hour per week of sprint length
Agenda:

What

Description

Who

Duration
h:mm

Confirm that the team has delivered on its
commitments

Review Sprint Contract
Summarize sprint results (stories, story points, effort, etc)
Note discrepancies between plan and actual

Scrum Master

0:05

Confirm that the project is on track

Review & Discuss Release Burndown Chart,
other key points as needed

Scrum Master

0:05

Examine the functionality which has been
delivered

A spontaneous guided tour, led by the
developers, through the new functionality in the product.

Product Owner and Team

1:40

Discuss functionality which was committed
but not finished

Understand what happened and why, but save
deeper investigation for the retrospective

Product Owner and Team

Up
to 0:10

Seven Principles of Lean Software Development

Lean Software Development has its roots in Toyota Production System and it helps software organizations optimize their processes and production methods in order to deliver their products to the market much faster and with better quality. Lean movement can be considered as a new development method that tries to identify and eradicate all problems and “disabilities” of old methodologies like Waterfall. Lean puts main focus on people and communication – if people who produce the software are respected and they communicate efficiently, it is more likely that they will deliver good product and the final customer will be satisfied.

Lean Software Development subsequently gave birth to Agile Software Development methods and its main branches like Scrum or Crystal Clear. For many people who know the subject Agile is just another word for Lean or Lightweight.

In one of the most popular books on Lean subject, namely “Implementing Lean Software Development – from Concept to Cash”, Mary and Tom Poppendieck explain how to implement Lean by following seven principles – principles that are some kind of Lean commandments:

  1. Eliminate Waste

    • Provide market and technical leadership – your company can be successful by producing innovative and technologically advanced products but you must understand what your customers value and you know what technology you’re using can deliver
    • Create nothing but value – you have to be careful with all the processes you follow i.e. be sure that all of them are required and they are focused on creating value
    • Write less code – the more code you have the more tests you need thus it requires more work and if you’re writing tests for features that are not needed you are simply wasting time
  2. Create Knowledge
    • Create design-build teams – leader of the development team has to listen to his/her members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible
    • Maintain a culture of constant improvement – create environment in which people will be constantly improving what they are working on – they should know that they are not and should not be perfect – they always have a field to improve and they should do it
    • Teach problem-solving methods – development team should behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them
  3. Build Quality In
    • Synchronize – in order to achieve high quality in your software you should start worrying about it before you write single line of working code – don’t wait with synchronization because it will hurt
    • Automate – automate testing, building, installations, anything that is routine, but do it smartly, do it in a way people can improve the process and change anything they want without worrying that after the change is done the software will stop working
    • Refactor – eliminate code duplication to ZERO – every time it shows up refactor the code, the tests, and the documentation to minimize the complexity
  4. Defer Commitment
    • Schedule Irreversible Decisions at the Last Responsible Moment – you should know where you want to go but you don’t know the road very well, you will be discovering it day after day – the most important thing is to keep the right direction
    • Break Dependencies – components should be coupled as loosely as possible to enable implementation in any order
    • Maintain Options – develop multiple solutions for all critical decisions and see which one works best
  5. Optimize the Whole
    • Focus on the Entire Value Stream – focus on winning the whole race which is the software – don’t optimize local inefficiencies, see the whole and optimize the whole organization
    • Deliver a Complete Product – teams need to have great leaders as well as great engineers, sales, marketing specialists, secretaries, etc. – they together can deliver great final products to their customers
  6. Deliver Fast
    • Work in small batches – reduce projects size, shorten release cycles, stabilize work environment (listen to what your velocity tells you), repeat what’s good and eradicate practices that creates obstacles
    • Limit work to capacity – limit tasks queue to minimum (one or two iterations ahead is enough), don’t be afraid of removing items from the queue – reject any work until you have an empty slot in your queue
    • Focus on cycle time, not utilization – put in your queue small tasks that cannot clog the process for a long time – reduce cycle time and have fewer things to process in your queue
  7. Respect People
    • Train team leaders/supervisors – give team leaders the training, the guidance and some free space to implement lean thinking in their environment
    • Move responsibility and decision making to the lowest possible level – let your people think and decide on their own – they know better how to implement difficult algorithms and apply state-of-the-art software frameworks
    • Foster pride in workmanship – encourage passionate involvement of your team members to what and how they do

If this brief introduction to Lean Software Development is still not enough for you I strongly recommend buying and reading Poppendiecks’ book “Implementing Lean Software Development – from Concept to Cash”.

Don’t Use Scrum

Photo (c) Janusz Gorycki

Models

Once upon a time, people believed that the earth is flat and the sun revolves around it. Then Copernicus came and offered the theory that matched the observed reality better. Then Newton attempted to explain why planets revolve (among other things). Then Einstein pointed out where Newton was wrong and straightened the theory to match the needs of his contemporaries – very soon to be superseded by a bunch of crazy physicists who invented quantum mechanics. These days, we pretty much know for a fact that quantum mechanics is wrong and we are in a search for a better theory. Now, all of the above theories have a couple of things in common:

  • they are purely theoretical and idealized models of the real world (yes, even the flat earth theory)
  • they were significantly better than their predecessors
  • initially, they fit the needs of their creators
  • they became the model to use, the latest craze, the offcial religion, the mainstream, displacing the previous models
  • over time the number of corner case where the models broke increased to the point where they were unusable
  • yet, the evangelists of the existing model fought hard to preserve them and to prove that suggested alternatives were pure lunacy (which, to be honest, 99% of them were)

What does this have to do with Scrum?

Well, everything – you saw that coming, didn’t you? All the development process definitions are theoretical models of the real world, just as physical models are. And they break in very simmilar ways. And the new, alternative methodologies are ridiculed and fought with similarly. And eventually become mainstream and break too.

So, don’t believe for a second that Scrum (or any agile methodology) is immune from this process. Scrum will be replaced by something better – just you watch. Right now, agile methodologies have just become mainstream, having relegated the previous models to the status of the ‘flat earth’ theories. Which is precisely the moment when they are doomed to start breaking in more and more situations – and the paradox is that many these scenarios were created by the very fact that we have become so much more efficient thanks to using agile development methods!

So the question is: does Scrum (or any other agile method) still work now? Well, I would say that it mostly does, but in some scenarios – it works just barely. And if you attend the ScrumMaster training, they will introduce you to all the caveats, patches and workarounds that are being currently applied to the „real thing” to make it still work in a real world. Like – what to do if your customer or a product owner is not embedded in the team – in the case of my team, they are on the other side of the planet! Or, what do you do when the customer will absolutely not accept anything else than a fixed price contract? Pass on the contract, as the Good Book seems to suggest? But see, I happen to like the money that the customer is offering, so I thing this is just crazy talk.

The Alternative

I can safely say that there exists one development methodology that is guaranteed to be matching your needs always: it is called „common sense”. Really, you happen to know much better what the needs of your projects are then Scrum consultants. You do need to familiarize yourself with what they are offering, you do need to read all these books. There is a lot of good practices described there, that will make your life easier. If you are crazy about certifications, by all means, go on, make yourself a ScrumMaster. But then – pick and choose. It is ultimately your responsibility to design your process so that it works for you. If the result ends up not resembling the „standard” process – that’s too bad for the standard.

The Effective Sprint Planning Meeting

Picture courtesy of Photocapy@Flickr

At the beginning of each sprint, the Scrum team
and product
owner negotiate the scope of the sprint. They have a limited amount of
time to discuss
and agree on the sprint backlog. The product owner wants functionality
implemented properly and to invest development dollars wisely. The team
wants a
mandate it can fulfill. And everyone wants the meeting to finish on
time! Here
is an agenda (complete with a downloadable template) to follow so that your sprint planning will be successful.

The purpose of the Sprint Planning Meeting is for
the
Product Owner and the team to negotiate what should be accomplished
during the
sprint, or as I call it, the sprint contract. (Scrum actually defines
two
meetings, a negotiation meeting with the product owner and a "let’s
figure out
how we are going to do this" meeting among the implementation team. But
I’ll
talk about the latter meeting another day).

Even though we value customer interactions over
formal contracts,
contracts can still be useful and I like to talk
about a
"sprint contract". It is simply an agreement between the Product Owner,
who
agrees not to change his mandate before the end of the sprint, and the
team,
who commits to delivering a defined set of functionality by that time.

Basic Parameters of the Sprint Contract

One of the best kept secrets of Scrum is that a
project
consists of a series of fixed time, fixed quality and
fixed scope
mini-projects, where each mini-project has a cost ceiling. Sum the results of all the mini-projects together and
you have
your release.

Since the sprint length, team size and definition
of done
are defined and fixed for the duration of the sprint, only the scope
might vary,
and even here, the team strives to define and fulfill a commitment.

Cost depends mostly on hours worked. The upper limit is known, but since things happen – like getting called to help another project or an unexpected doctor’s visit – the limit is seldom reached. So you have a cost ceiling.

Quality is expressed though the definition of
done, and
should only change occasionally.

As all the parameters are fixed for the duration
of the
sprint, the only thing to agree on is the scope. Although not a
parameter
of the contract, the expected velocity helps set the expectation of how
much
can be accomplished in the sprint.

Staying within the Time Box

The Scrum Master moderates the meeting, but the
Product
Owner comes with the agenda. S/he wants functionality delivered and to
ensure
that the overall project is on track.

Regardless of the length of your sprint or size of
your
team, preparation is the key to finishing on time. If you are
unprepared, the
meeting can really drag on!

Before you start, the Implementation Team(s)
should have
seen, understood and estimated the stories. The stories should be small
enough
to implement in one sprint. The acceptance criteria should have been
defined; this
greatly improves your chances that the product owner can accept the
implementation on the first try.

The team should know how much capacity they have
available.
So vacations, training, company events, and other commitments should be
known
and accounted for before the start of the sprint. Some events are
unpredictable, in which case you just make a reasonable guess as to how
much
capacity they will consume, agree with the Product Owner on priorities,
and
then accept some stories as "conditional" – those you will do if you
have time.

A Simple Sprint Planning Meeting

I have used this structure in a number of
contexts,
including a case in which the product owner paid for the team by the
hour and
another with distributed teams on two different sites. How formal you
need to
be will depend on many things, including the size of the project, how
well the
project is going, the commercial relationship between product owner and
team,
how well parties cooperate, etc. The more challenged the project, the
more you
need to dot you i’s and cross your t’s.

  • Review the basic parameters – start
    & end date, time and location of the sprint review meeting, team
    availability and definition of done
  • Present & discuss each story. A
    time box for each may be useful to keep to whole meeting on track.
    Holding a reserve at the end of this section for difficult stories
    often makes it easier to move on if the discussion is getting stuck on
    one story.
  • Commit to the stories. Go through the
    list, one at a time and in order of priority. Get the team or a team to
    commit each one until no one will commit to any more.
  • Agreement. Confirm the list of
    committed stories with the Product Owner.

You can download the meeting agenda, which also includes suggestions for time-boxing the individual sections

As Scrum Master, I have found it useful to confirm
the Sprint
Contract with an email to the Product Owner. A picture of the task
board, a pdf
of the spreadsheet or a screen dump of the wiki page can be an
effective way to
capture the agreement. Everyone is clear on what should be done and
both
product owner and team have a solid basis to examine the success of the
sprint
and the overall state of the project at the sprint review.

My First Agile Project: The Last Mile

Picture courtesy of Dru Bloomfield on flickr

Welcome back to My First Agile Project. I spent a few weeks doing as little as possible for the holidays but now that I’m back at work we’re starting to head toward the actual end of this project. For real this time; barring any natural disasters, stress-induced insanity, or alien invasions we should be live by the end of the month. So the next couple of posts in this series are going to be about the end of My First Agile Project as we complete this and transition to whatever comes next.

As I’ve discussed before, we’ve missed a couple of other deadlines in the past but this one just feels different. On past deadlines, when we thought we were close enough to done we’d find a 3-day weekend and try to decide if we could finish everything by then (converting all of our old data takes a long time so we have to basically shut the company down while we do it). Of course, things come up and we’re too optimistic so when it comes down to it we’ve had to abandon the previous dates. We thought we were going to be able to do it at the end of November but again we missed it due to changes being made at the last minute and unforeseen problems. This time though, our list of remaining issues is small enough that when we decided on this new date we were all a lot more comfortable with it than in the past. This feels like an actual date of completion for everything, not a deadline we’re rushing to meet.

That doesn’t mean we’re not stressed, this project has been almost 2 years in the making and coming to the end makes everyone wonder just what we’ve missed and how things will really go once we’re live. But overall, not having the stress of being forced to work faster just to finish everything before an artificial feeling deadline is much better.

Now, one thing that’s missing from this whole process is Scrum or Agile. In previous installments of this series I’ve mentioned how we drifted away from using the Scrum processes when we thought we were getting close to the end and since the end kept moving away, we never went back to it. We’ve been going in and out of scramble mode for months now, with the only plan being that we work like crazy on our various pieces of code trying to squash bugs found in testing. This is obviously sub-optimal and I wish we have kept our discipline about planning and sprinting. Although I do wish there was more to read out there about the actual nuts-and-bolts of using Agile/Scrum at the end of a project. If you have suggestions for reading material, please comment at the end of the post.

Side note on coaching

I’ve been thinking about coaching more since I wrote Part 14 of this series and I think this is a place where we could have really been helped by an outside coach. Having somebody who could have helped us with the nuts and bolts of how to stay on track as we near the end would have been great since we obviously were just stumbling around in the dark. I’m now of the opinion that if you’re doing your first Agile project and it’s more than a year, you should find a coach after a few months to see how you’re doing, then check back in with that person periodically. I’m not even sure if Agile coaches would work this way but I think this would have helped us tremendously. The end of a project is a chaotic time and it’s easy to get lost.

Okay, back to the topic at hand. The last week has been basically a wrap-up week for a few of our bigger pieces. I finally finished 2 reports I’d been assigned months ago and have rewritten multiple times since then as new requirements came in (if you’ve been following me on twitter you’ve seen my cursing and threats of violence about these reports). We finalized and tested our document printing process with the folks in the company who handle printing. We don’t have any more issues with either of our invoice production processes. Just the fact that these pieces are Done now is a huge weight off of all of our shoulders.

As of Friday our code is frozen and our testers will be doing heavy-duty regression testing all next week. They’ve pretty much been doing regression testing all along so I expect this will go well. When issues pop up this week we’re going to take a hard look at the importance of the issue and the fix to see if we should put it in or wait. If all goes well, we should be able to shut everything down on Friday and start the real-deal data conversion process and put this beast into production. My fingers hurt from all the knocking-on-wood and crossing they’ve been doing talking about going live so in the interest of superstition, that’s the end of this article. 🙂

Stay tuned next week for either a tale of triumph or woe, depending on how the launch went.

Seven Principles of Lean Software Development – Eliminate Waste

Picture courtesy of Phil Romans@flickr

Peter Stevens in his newest post advices how to deal with current crisis using Lean methodologies. One of his advice is to eliminate wastes, not costs. I totally agree with it, more so it is one of the most important (at least for me) principles of Lean Software Development.

Software development organizations should always strive to produce the best products and to deliver only features that are of paramount importance to their customers. They should always try to develop those 20% of functionalities that represent 80% of the value. This need is more vivid and desired during such global business conditions. This could apply to all types of enterprises – you should eliminate all unnecessary steps and waiting periods; you should strive to get the value as soon as possible and to get only pure value without any waste.

In this post I will try to explain “Eliminate Waste” principle from “Implementing Lean Software Development – from Concept to Cash” book.

Provide market and technical leadership

Your company can be successful by producing innovative and technologically advanced products. Important thing here is that you understand what your customers value and you know what technology you’re using can deliver.

You don’t necessarily have to invent something that is new and unknown. Note that the richest companies just replicate good ideas adding just few features that are unique and that satisfy customers (e.g. Google Mail, JIRA issue tracker).

You can be the market and technical leader by improving existing ideas and fitting them so that the final product will attract more customers.

Create nothing but value

You have to be careful with all the processes you follow. Be sure that all of them are required and they are focused on creating value.

If you are e.g. creating lots of documents that have been always produced but nobody really knows why and you are pretty sure nobody reads them – it sounds like waste you have to eliminate. Another example of waste is when you have to wait for a long time for some other department or team to answer your questions or uncertainties and this waiting period always stops you from moving forward. Waiting is the most apparent and obvious waste – though it is not always easy to eliminate.

You should measure your process cycle efficiency and strive to keep improving it – it will probably never be perfect but it can be constantly getting better and better.

Write less code

This advice is quite aggressive and when you work in old-fashioned waterfallish organization saying that you should limit the features in your system to only those that are absolutely necessary and deliver value can be perceived as some kind profanation. Well…. it’s not.

The more code you have the more tests you need thus it requires more work and if you’re writing tests for features that are not needed you are simply wasting time. If you don’t have tests (is it possible?) it’s even worse – there is bugs in a code that is not used and they will appear in the least predictable moment. I personally remove a lot of code when I take over some projects. I focus on the required features and remove all stuff that I “may need in the future”. The rule is simple: if you need it, add it – if you don’t need it right now, remove it. Another argument standing for writing less code is that usually with less code the overall complexity is lower and the code base is easier to understand thus maintain and support.

Last thing – the easiest way to identify unnecessary code is to use code coverage tool. More details can be found at the provided link.

Eliminate Waste

I hope pieces of advice given above will make it easy to understand how to put “Eliminate Waste” principle, which is the most important one IMHO, in practice. If you need more detailed description with more examples and more sophisticated explanation you should definitely go to “Implementing Lean Software Development – from Concept to Cash” book.

PS. Six remaining principles described earlier can be found here:

  1. Respect People
  2. Deliver Fast
  3. Optimize the Whole
  4. Defer Commitment
  5. Build Quality In
  6. Create Knowledge

Mastering the Recession with Lean, Agile and Scrum

Around the world, companies are challenged by the financial crisis. Companies face declining revenue and fixed costs. Lean, Agile and Scrum help your company at all levels to focus on doing the right things, like creating value for your customer and eliminating wasted cost and effort, to get you company back to profitability. Lean, Agile and Scrum help you focus on getting the right Vision, Values and Execution to meet challenging times. Now is the time to start the discussion with your top management.

Your CEO wants your company to survive and even prosper during the recession (and we’d all be happier if there were no recession or if we could turn it around quickly). Together with Sales and Marketing, the CEO is trying to figure out whether and how much sales will dry up in 2009. He is under pressure to cut costs. If he does nothing, the company will be stuck with the fixed costs, but not have the revenue to pay for it.

Cut Wastes, not Costs

Lean is an adaptation of the principles of lean manufacturing to software development. Pioneered by Tom & Mary Poppendieck, Lean explains (particularly to management) why agile works.

Lean thinking helps management and staff focus on the right problems at the right time:

  • Create Value for your customers. Dieter Zetsche, CEO of Daimler sums it up: “The best cure for the crisis are convincing and innovative products” 
  • Eliminate waste. Anything with does not provide value for your customers is wasted effort which should be reduced to the minimum.
  • Improving to Time to Market is a powerful cost reduction tool. If you can bring out a product in half the time, then you have half the development costs, half the carrying costs and you see a return on investment in half the time. (If in doubt, ask your CFO what that means).
  • Multitasking is an expensive form of waste because it increases time to market. Would you overload the database server at the center of your enterprise services? Of course not! The long response times would drag everything to a halt. The same is true of management and project teams. So deliver as quickly as possible by focusing on doing few things well.

Concentrate your efforts. Get new products and services “out the door”, one after the other. Get your corporate response times to a minimum.

Create a productive climate

Agile values ensure effective information flow. Openness, Honesty, Courage and Trust ensure that everything which must be said can get said. If your staff fears for their job, or fears the consequences of telling the truth, they will be less willing to raise difficult issues. If your staff do not trust each other to do a good job, then people will devote energy to proving themselves or shielding themselves from blame. All these activities detract from your company’s mission to create value for its customers.

Adopt agile value to create an environment where

  • Staff at all levels trust each other to do good job. 
  • Everyone can tell the truth, the whole truth, even in difficult situations.
  • All Stakeholders in a project have access to complete and correct information about the state of your projects.

Create great products and services

Agile is also a set of practices. For instance, Incremental Delivery means products are ready quickly for the customer (80/20 rule) and ROI can start quicker.

User Centered Design provides the basis for creating great products and services. Get inside your users heads. Understand what they want better than they do. Create a product which meets their needs, even the ones they didn’t know they had.

Create those innovative and convincing products, which give your customers products and services that they just have to buy.

Strive for perfect execution

Scrum organizes work based around simple principles to produce concrete results predictably and with ever improving productivity. In a company organized around Scrum, everyone knows what they have to do:

  • Top management provides Vision, Focus and Flow.
  • Middle Management eliminates impediments and drives productivity upwards.
  • Self organizing, interdisciplinary Scrum Teams solve problems and deliver solutions.

Vision is about knowing where the company — and each project — is going. Focus is ensuring that people really act to accomplish the defined goals (without distraction). Flow is having a continuous supply of work, not too much and not too little, so that the company can consistently and predictably deliver new value to its customers.

Scrum rituals ensure everything which must be said does get said. Continuous Improvement means your productivity will be at least 30% better by the end of the year than it is today.

The way out of the recession

For each company, the way out of the recession means getting customers to buy your products and services. So follow Dieter Zetsche’s advice and give them something wonderful to buy.

Get you top management interested in the problem and the solution. Tell them you want to their support for a pilot project, which will 1) create an innovative new product this quarter (which your customers will just have to buy next quarter), and 2) show how Lean, Agile and Scrum lay the foundation for a highly competitive enterprise. You will need 1) their support and involvement, 2) an interdisciplinary team of 7 to 10 top people from your around company -all the experts needed to make a new product and 3) probably some coaching and training to make it all work effectively.

Then go create something wonderful!