Agile – Page 3 – Rick Tonoli

It’s about people…

“Individuals and interactions over processes and tools”

I’ve been thinking recently on the importance of people in this whole agile “thing” (for lack of a better word). I think people lose focus of the actual PEOPLE in a team and still focus on them as resources (some nice baggage from our waterfall days). Agile pushes the concept of a team thinking and working as a unit but I think it’s easy for individuals to become “lost” in this team and forgotten. Don’t get me wrong, I agree on the “team” mentality but people should also not forget about the individuals making up the team.

A simple question, as a “leader” of a team (ScrumMaster etc..) when last have you actually tried to find out if everyone is still “happy”? When last have you interacted with the person as a person and not a resource? I think, to some degree, personal interaction is important. Take a ScrumMaster for example; one of the key things they should be doing is “removing impediments”; often people think of these as purely work centric issues but what if they’re not? What if a team member is experiencing personal issues? This will definitely have an effect on the velocity of the project so why should you not try to help (or at least be aware of it)?

I guess what I’m saying is do not depersonalize the team, reducing them to “agile resources”; make people feel like they’re not only part of a team, but that they’re an indispensable individual within that team…

A new challenge…

Today is my 3rd day as an official ScrumMaster. Although the first 2 days were, well, daunting at best, today there seems to be a bit more clarity. The challenges here are similar, but still different. Resistance to adoption is coming from a different place this time. The teams seem to want to do Scrum (at least it appears that way), although there is ALOT of area for improvement. There is some frustration from management and this is starting to flow over into the teams and cause people to disbelieve the effectiveness of an agile approach (I guess it’s a classis “blame the tool” scenario). I think the frustration comes from the misdirection that exists in the way the teams are applying Scrum. Off the top of my head and based on a few days of observation the following are big issues that need to be addressed:

There is no visible prioritized product backlog with no obvious release plan (I believe this is where the main frustration comes from)
The teams have no burn down charts, they seem to be relying on the tool (Version One) for this, but without the discipline of keeping it up to date, it’s not really useful. Another reason why I don’t really like tools, people place too much reliance on it and fail to realize that it’s not using the tool that’s important but rather that something actually gets done.
There is a need (and lack of) a Scrum of Scrums to co-ordinate the effort between the teams.
The daily stand-ups are not focused co-ordination meetings and often break down into general discussions, sometimes “chickens” even take control of the show.
The impediment lists aren’t being managed (and aren’t prioritized)

There are other smaller places of possible improvement, but we will need to fix the larger issues first.

Overall I’m a mixture of excited, confused and nervous about the next few days. Where I had the advantage of already having earned the respect of the previous companies team I now find myself sitting with the the daunting task of having to re-earn respect. I do not believe in telling people what to do but rather in having them do things because they feel it is the right thing to do, for that to happen people have to respect you and your opinion and believe in you. Until that comes I will fall back to process and hopefully the respect will come when my opinion creates value for the team(s).

Let’s see how things go…

My First Scrum Board…

This was my first attempt at a usable scrum board. There are some flaws, like the blank story card in the Product Backlog?! (only noticed this now, no idea how that got there, will have to find out) and the fact that there’s a story that has no tasks assigned to it yet is not in the DONE area. I think it worked pretty effectively, especially the use of colored post-it’s to represent different “types” of tasks (tests, bugs, impediments etc.). I say this because I was able to pull in random people (business) and ask them if they understand what is going on here, and, with some basic explanation of the process, they understood perfectly. For me a true test of an “information radiator” is if a stranger can look at it and, given the basics, understands it reasonable well.

Some things that I’d like to add include the teams definition of “DONE” and perhaps the three questions to encourage people to focus on the purpose of the daily scrums.

Thoughts or ideas on improvement (or something I’m missing)?

The bottom left stack of post-its are what we classified as “production issues” directly affecting business, which the team chose to tackle as they came in. The result was that it clearly shows we have a problem with existing systems (the sheer number of critical “issues” the team had to deal with).

Change…

The new year will bring a plethora of change in my life, a new company, new goals, new challenges, new ideas. I must admit I’m eagerly looking forward to this much like a new astronaut looks forward to his first space flight, nervous excitement I guess would summarize it.

Along with this I’m also a little sad about leaving my current employer. I’ve been instrumental in growing Scrum to where it is at the moment and I have to say that, although there is still alot of room for improvement, it’s just reaching a point of “proving itself” and getting it’s feet, and now I’m leaving. Lets hope the passion I tried to push it with rubbed off and that it will continue to improve on itself and a new champion will step up to fill the gap. The team(s) I worked with have reached a point now where they are reasonably self organized, so there will be no problem there. I think the possible impediments to continued growth of Scrum will be:

The lack of a strong ScrumMaster/Coach to protect the team(s) and nurture the process.
Inteference from management due to “command and control” culture.
Breakup of the existing team(s). Although this may prove useful because they may end up “infusing” the other team members.
The warping of the process in order to hide problems.

I’ll have to come around here in a few months to see how things are running…

A journey…

As I delve deeper and deeper into “Scrum” and read more and more blogs / papers on the subject I keep fixating on the same question… “What does it mean to be a ‘ScrumMaster’?”. Yes, I know there are the standard “definitions” of it but I think it’s more than that. Personally I equate it to a journey, a kind of never-ending journey of improvement, both to self and to everyone you touch. I do not think it is a methodology, I do not believe it is even a process, I simply believe it is a set of guidelines that set you on the path to greater understanding and improvement.

My own personal journey has been interesting, and I’m sure will be for a long time to come. I started off thinking Scrum was “the silver bullet” that will solve all problems, but the more I read and the more I try to apply it the more I realize it is not a solution, it is merely a way to find a solution, and that almost every day the more I practice it and the more I experience it the more I realize that it’s core purpose is actually to expose places of improvement!

Along these lines I believe that the job of a “ScrumMaster” is to improve the world around you to a point where you become obsolete, so, the act of becoming a “Master” of “Scrum” is the act of mastering the art of exposing areas of improvement and acting on these immediately and to the best of your ability, and then taking the results of this and feeding it back into this continuous loop of inspect and improve.

Following this I think (some of) the greatest strengths of a “ScrumMaster” are:

To truly observe and listen, without interfering.
To act without hesitation, but with a certainty based on knowledge backed by experience.

I welcome any thoughts on this, am I wrong? Am I at close?

Affinity Estimation

“Affinity Estimating is a technique many teams use to quickly and easily estimate (in Story Points) a large number of user stories. This is a great technique if you’re just starting a project and have a backlog that hasn’t been estimated yet.”

I remember this topic came up during the ScrumMaster course and I found it quite interesting, I’ve finally found an article related to it on Kane Mar’s blog, have a look at the entry here. I’ve yet to try it but will when I have a project with a huge amount of stories, it sounds like it can work quite well.

Impediment

Impediment: That which impedes or hinders progress, motion, activity, or effect.

I’ve been thinking about the negative context “impediments” are sometimes set in, I don’t think impediments are negative at all, in fact quite the opposite, they are the pointers that lead you on the path of improvement, but it all depends on how you approach it I suppose. I think the important thing to remember is that there is a distinct difference between removing the SYMPTOM of the impediment versus removing the ROOT CAUSE. Yes, both will have the effect of enabling the team to continue, but fixing the ROOT CAUSE will lead to a permanent improvement potentially across the organization, you may even end up removing OTHER teams impediments!

A good example of this is something I myself had to deal with. Our team(s) rely heavily on a web service supplied by another part of the organization. Occasionally this web service supplier will do routine maintenance and bring down the service without informing anyone, bring development to a grinding halt. Our current way of removing this “impediment” is to contact them and request they restart it as soon as possible (fixing the SYMPTOM). A better solution would possibly be to set up a meeting with them and discuss how they can involve us in their maintenance planning, or at least inform us up front of scheduled maintenance, allowing us to plan ahead for these down times (aimed more at the ROOT CAUSE).

Talking to non-agile people…

As much as I know (or think I know) about Scrum I still find it difficult some times to communicate to non-agile (waterfall) people that are resistant to change and passionate about their point of view. An interesting article I found clarifies this a bit for me, specifically how to communicate with project managers. The essence of it is to communicate to them in their own language, in terms they understand and can relate to. The article can be found here:

How to Talk to Project Managers

What does it mean to you?

I thought today on the importance of certain words in an organization, like when people say “We’re DONE” what do they mean? When they say “This project was a SUCCESS”, what exactly do they mean by “success”? These are important “words” or phrases that any company must define clearly for it to run effectively.

Along these lines I found two nice podcasts on hanselminutes.com, one entitled Lean Software Development with Tom and Mary Poppendieck which has a good approach to defining success; and then What is Done? – A Conversation with Scrum Co-Creator Ken Schwaber which talks about what it is to be done. Both of these are well worth the listen.

Epiphany…

Epiphany: a sudden, intuitive perception of or insight into the reality or essential meaning of something, usually initiated by some simple, homely, or commonplace occurrence or experience.

I’ve always struggled with accepting the concept of estimating using story points and NOT effort hours. I could never get my mind around the concept and yes, I’ve read a lot about how estimating with hours is bad (people pad, management argues that real time <> estimated time, team members feel pressured etc etc…), and I believe this, however I did not understand how bad it was until today.

During our estimation (still doing hours effort estimation) we were trying to define the tasks necessary for a story to be completed, however the story had a “task A” that would lead to several “task B’s” that were known, however no-one could (and neither should they be expected to) estimate the hours effort on the “task B’s” simply because the input from “task A” was critical to the timing! Now you’re stuck with tasks that are KNOWN, but cannot be TIMED. And then the light went on and I realized why estimation with time was so bad…You may KNOW everything you need to do (the complexity), however you may not necessarily know how LONG everything will take (the effort), in other words, you know COMPLEXITY but you cannot measure the EFFORT. It now makes sense…