As have many others, I’ve seen different interpretations of what Agile means to different people in different environments.   From my experience, people generally consider Agile to be a ‘state of mind’, a particular practice or a set of practices.  I worked with a team in the past that considered themselves to be ‘very Agile’.  They were Agile enough to have a 4 day sprint after a 2 week sprint because all the work couldn’t get done in time.   I’ve worked with teams that had development and testing sprints.  I’ve worked with teams that had programmers that would account for re-working bad code in any story that was going to require changes in those areas.

Does that describe what Agile is?

I dunno.

The interesting part of those 3 stories is that the environments and culture created those versions of Agile, for the lack of a better phrase.  The 1st team that couldn’t seem to finish work in any sprint thought they were really Agile.  They thought this because there was no impact to missing the sprint commitment.  It didn’t really matter when the work was done or when it was released.  Using ‘sprints’ was just a way to break the work into 2 week chunks.  I’d call that iterative, not Agile.

The 2nd team I mentioned was in a larger company with very strong functional silos that were stronger than the team itself.  Some call that ‘mini waterfall’.  I don’t know what I’d call it other than that was the best these guys could do at that particular time.

The last team I mentioned was one of the best teams I ever worked with.  They all got along well, they all understood the application from a technical perspective and a user perspective and most importantly, they gave a damn.  They were a passionate group of people who challenged each other and just liked doing what they were doing despite the constraints they had as a result of their environment.

So is Agile a state of mind?  A single practice? A set of practices?  A couple of years ago I wrote a post about how I learned organization culture is the most important aspect of becoming Agile.  That seems to still ring true for me.

To me, Agile is like the old Lexus slogan from the 90′s.  ”The Relentless Pursuit of Perfection”.  I went to the Toronto Agile open space this past weekend.  That’s what Agile is all about.  People giving up their free time and time with family and friends to share ideas and learn about something.  There’s something special about these people.  There’s something intrinsic that drives these people to be better.

You can’t package that up and install it into an organization.  You can, however, package up and install a set of tools and practices into an organization.

My Agile is the former, yours may be the latter.  And that’s ok.  Just be aware of what you and your organization is capable of and choose your Agile adoption path to align with your culture and values.

That reminded me of a recent sprint planning session our team had.  Our product owner considered customer value and done as being able to clearly show separation of presentation and data layers in a new service we’re developing.  I considered customer value being showing the user of the new service a simple interpretation of the data being shown through the service.  Very different perspectives.

For me ‘done’ is when the customer gets something valuable.  For our PO, ‘done’ is when he can be satisfied with the design of the service.  The team, done is when all the yellow stickies are moved to ‘done’.

The point is, my tax example is simple and very specific.  Just before I wrote this post I told my wife I finished both returns, filed mine since I get a refund and will file her’s at the deadline since she has to pay this year (booooooo!….for her!).  Before that, I have no idea what she thought ‘done’ was.

Software is much more complex than that.  One way of handling this is to periodically align the team during the sprint.  Oddly enough I did that yesterday.  Our standup felt kinda ‘status-y’ and there really wasn’t much talk about the actual work.  I pushed the team and asked them to say what they thought we agreed to delivering.  I asked the PO the same thing.

I was pleased to hear it was the same as what I thought so I wrote it down and stuck it on our release wall.  Might be tough to see in the picture, the green card on the left shows the sprint number and what our definition of ‘done’ is from the customer’s perspective since that’s what our sales and marketing team would find valuable.  They could care less if the service is de-coupled.

When you talk about ‘done’, be specific.  Scrum talks about delivering ‘business value’ and ‘potentially shippable’ software which is just a guideline.  Be specific and you’ll avoid a whole whack of ugle “hey, that’s not what I thought we were gunna get!” conversations later.

1. what did I do yesterday?
2. what am I planning on doing today?
3. what’s in my way?

I’m amazed at all the grumbling I hear from new teams I work with about these evil Agile people are forcing you to stand-up when Ken’s book clearly says you don’t have to stand!  Actually, one of the team members actually threw that in my face so I re-iterated the purpose of the stand-up to them.

Bob Hartman tweeted me with a great idea a while back.  Why not let them sit?  Simply plot along how much time they take to do the standup when sitting vs standing.  The team admitted to me that when I wasn’t there they would sit down so I didn’t want to be forcing them to do something they were against.  Isn’t it a bit more Agile to let the team do what works for them as opposed to being worried about breaking the golden rule of standing up?

Here’s the observations after a few iterations of comparing sitting vs standing.  To put some context around it, our team isn’t completely co-located.  We’re all in the same general area and a few sit next to each other but since we’re in a huge environment we agreed (as a team!) to do our standups in a neutral area so we don’t bug the people around us.  Oddly enough there is a waterfall in the building, that’s where we do our standups.

When standing:

• people drift further apart as it goes on
• body language is terrible, they seem to be there out of habit, but they do still get value out of it without really realizing it
• they address me, the coach and temporary Scrum Master
• averaging about 12 – 15 minutes
• each person answers their 3 questions (except for blocks, I usually just recognize them and so do other team members)
• seems very regimented in nature and not natural

When sitting

• they sit closer together
• body language is MUCH better, they actually lean in towards each other
• they address EACH OTHER.  Sometimes they look at me but they are more team focused for some reason
• averaging 15 – 20 minutes, still followed by follow-up conversations
• they do get sidetracked by trying to address blocks and I have to reign them in more often to stay on track

So far the experiment is showing me that they are getting much more value out of sitting than standing.  Sure they are taking a few minutes longer and I have to pull them back on track sometimes, but they are much more engaged and working together while sitting.

I’m sure part of what helps with sitting is that we have to walk to another part of the building as we don’t have a dedicated team room yet so I’ll follow-up with another post once we have that environment.

Do your teams sit?  Would love to hear your stories.

1. Agile Evaluation: What do you expect to see when you first visit an agile organization?
2. Project size: Which approach works best based on the size of the project?
3. Estimating and Planning: Which approach is more accurate?
4. Requirements Management: Which approach is more effective?
5. IT Governance: which approach addresses this better?
6. Distributed Development: Which approach makes this easier?

Obviously the panelists’ opinions were skewed towards Agile having the ability to approach these more efficiently, but the key message overall was that even with using an Agile approach, culture, learning and constant improvement are the corner-stones to succeed with Agile.  To be successful in the areas being discussed, focus on building trust, relationships and make a commitment to improve.  They all really drove this point home in each topic.

Regardless of discipline, framework or methodology being used, it was pretty clear that corporate culture was the key.  There must be a mutual respect across the organization and within  teams and there must be a commitment to learning and constant improvement for Agile to really work.

I’ve always had the opinion that using Scrum, XP, Lean, Kanban or whatever you want to use is irrelevant if the culture doesn’t buy into the concept of what it really means to be Agile.  I’ve read many articles where people debate the use of Scrum vs Lean and nitpick about stuff that doesn’t matter such as “well, you can’t be Lean and use Scrum, they are 2 different approaches with different attributes.”

Who cares?

Yes, that’s right, who cares?

Being Agile is all about finding a better way to work and move forward as one team or organization, not worrying about whether or not you’ve followed the Scrum checklist (not that there is one, but we all know people love lists that tell them what to do).  This isn’t some hokey notion or religious argument, it’s common sense.  Give people the opportunity and trust them to do the right thing, and more often than not, they will.  Succeed as a team, fail as a team…but LEARN from the failure and move on.

This has been quoted many times by Agilistas, my apologies for not knowing the source to credit them, but the saying goes “It’s not my problem, the hole is in their side of the boat” This is the type of thinking that must change in order to be successful with Agile.

Now the challenge becomes, how do you help people adopt Agile culture?  Let me know what you think or drop me a line with how you’ve approached changing culture when adopting Agile.

Oh, and look for a follow-up on extremely short sprints for small teams, we learned quite a bit but I’ve been a bit swamped lately to follow-up.

There are a few problems with this but the main ones are:

1. product team isn’t exposed to REAL client feedback/issues
2. Implementation team gets bogged down with client requests
3. less team-wide knowledge sharing (read: specialists)

We had been operating in 2 week sprints and when you are supporting existing clients you can’t really tell them it’ll take 2 – 4 weeks for any request they submit.  As a result we re-prioritze often (which is good) but it’s definitly not in the spirit of sticking to Scrum (which is bad).

So here we are at day 1 and the plan is:

1. 15 minute planning session
2. 1 ‘daily’ standup (5 minutes at ‘mid-sprint’)
3. 15 minute retrospective and sprint review

This is going to be tough on everyone and there was some resistance to trying this method from the team but after a discussion they were willing to give it a shot which is great.  At first the phrase “it’s impossible to do anything in 1 day” was thrown around quite a bit but I think they will realize very quickly there isn’t much of  difference between 1 day sprints and 2 week sprints, you simply scale everything down to fit.

I expect some interesting results and would love to hear from others who have tried this method.  Leave me a comment!

Change needs to start somewhere and usually I find the people in control are most often the toughest nut to crack out of the gate.  Here are 3 simple tactical steps that can help point you in the right direction to implementing Scrum.

1. Recognize the need for change: As the saying goes, if it ain’t broke, don’t fix it.  If waterfall or adhoc project management is working well enough, don’t change it.
2. Start with a daily standup: Even if you continue to use waterfall or adhoc methods initially, start with a quick time-boxed standup meeting with the team.   In large organizations it may be necessary to have a “scrum of scrums” meeting if the project team is too big.
3. Hold a weekly retrospective:  this is very important.  The best way to fix something that’s broken is to talk about it.   Talk openly and honestly about what’s working and what’s not working and try to make a small improvement during the next week.

Yes it could be that simple to start off.  Obviously your mileage will vary depending on your organization, but start small and make incremental improvements over time.

The benefit you receive will be that, for starters, you recognized that something needed to be changed.  Second of all, showing a commitment to the team that you (the project manager or defacto ScrumMaster) are prepared and dedicated to making the situation better it’s a giant step for the team.    As a ScrumMaster, your job is to protect the team and ensure project success.  By having quick daily standups and frequent retrospectives you will see the team’s problems rise to the surface very quickly and you will need to take action to remove those roadblocks.

The benefit of starting in the trenches is that the time spent implementing this approach is minimal and if there are political issues that would prevent process change, this approach essentially ‘flies under the radar’ to those who would oppose it.

I’d love you hear your thoughts about problems you’ve had implementing Scrum or issues you would see based on your unique organization.  There are many approaches to take, but again, start small and make incremental gains and you will find the value in Scrum.

Forming: doing something new is always fun, shakeups seem to spark more interest and commitment

Storming: the team realizes that it’s pretty hard, management sees the process “failing”, critical that the Scrummaster remains a solid coach

Norming: the Team starts to get into a rhythm, more Scrum rules get adopted, the team starts to self-manage better

Performing: the Team “gets it”, they adopt XP practices, self-manage almost entirely by themselves and really crank out great value

Seems logical enough for me, and having spent the last 4 – 5 months re-implementing Scrum I can say these are the phases we went through.  I constantly refer back to my CSM training and am quite pleased I documented the process as far as where I was before it started and how I could relate what I learned practically.  There are many negative “Smell of Scrum” type of posts everywhere, I am choosing to focus on how we de-funk-ified the smell.

I’m sure most Teams new to Scrum go through these same transition phases, here’s some of the bumps we hit along the way and how we dealt with them:

Forming

We have a small team filling support, professional services and development so there is overlap with the folks in the group.  After some spirited lunch and learns with management and the team to point out what we were doing wrong, we all bought into the process.  That’s the short version, it can be rough to be told you are wrong, but the point is we were ALL wrong.  You fail, then you learn.

The Team was given 2 scenarios for handling the structure of the team, one being more client facing, the other strictly development.  These scenarios outlined the pros and cons for each and at the end of the day the team chose to have 1 team for all of it.  All was good.

Storming

The Team learned pretty quickly that the same people took the client related stuff and the same people took the development stuff.  All teams are different, some people are great at certain tasks, others, not so much but the point was they were resorting back to the way it always was and there was some visible stress amoungst the group.  I preach truthfulness and honesty constantly but it was understandable that folks didn’t want to call out other co-workers who they felt were under-performing.

Management was then starting to see lower productivity and they weren’t pleased, but I was happy the team was learning and re-iterated the importance of letting the team figure this out themselves with my coaching.

I introduced a few processes along the way:

• daily scrum tip: started with the foundations of scrum, truthfulness and then tips based on output of the previous day that would help
• Q&A: encouraged each team member to bring a question each day in “stump the scrum master” type of fashion
• $5 for being late to the standup (to prove a point, I was late on purpose the first day(shhh, don’t tell them!)  to prove to the team I am committed to the process and I am not exempt from this rule.)
• Scrum scorecard: rated how we were following the rules

The Team decided after 3 or so sprints they needed to keep the process, but split the team back into Client/PS and Dev teams.  Our retrospectives revealed some dysfunctional activities but we worked through them.  I could see the clouds clearing up so I knew we were coming out of it.

Norming

The business started prioritizing better and providing more visibility into what was coming down the pipe so the Team could now understand context of what they were building instead of “you tell us what to do, we’ll do it”

Since we were following the rules and clearing technical debt we really weren’t establishing velocity so we started estimating bugs for the sake of getting better at estimating.   I am sort of half-product owner as well as scrum master so I constantly hammered on business value and let the team decide how to achieve it.   As long as they understood the business value, they would do the right thing.

Initially the team wasn’t completing all the tasks in the sprint so there was always spillover but they got better at it as time went on.  We still miss a few tasks, but by and large we’re ‘done’ at the end to the point where it’s shippable and they can show business value at the demo.

Performing

After some pain, arguing, lower productivity and fun retrospectives the Team really started getting the hang of it and at the end of our last sprint delivered substantial business value and managed the sprint themselves.  To put some context around it, the Team originally thought the Scrum Master was a project manager and was responsible for organizing the sprint, creating the agile wall, setting up the demo, reminding the team to wash their hands after they use the bathroom etc.  When they hit this phase, they really understood that THEY are the process.

The business was also pushing for “more, better, faster” and has since learned that’s not the way to go.  Trust the team and you’ll get results.

These are a few of the things the team is doing now that they weren’t doing well or at all before:

• writing their own tasks and breaking their own dependancies
• creating their own agile wall (I always iterated that the wall was for THEM, not me)
• entering their own issues into our tracking system
• adopted TDD and work agreements/rules within the team (that was based on management drive priority of zero defects and “do it right, not fast”  That was based on a release the failed miserably due to “do it fast”)
• given value only, not a solution or a demand by the business
• defined done for tasks, stories, sprints and releases

In the case of the last sprint, the team was given a business goal and accepted the stories into the sprint.  During the sprint our architect came up with something that would provide much better ‘bang for the buck’ and the team accepted their own scope change into the sprint all the while keeping the existing scope intact.  Let’s just say they knocked it out of the park.

The moral of the story is, when applied properly, Scrum works.  I cannot stress this point enough, trust the team, support them and do not give up.  The whole company needs to buy in to the process or it simply will not work.  Scrum is easy, implementing Scrum is very hard and requires a change in mindset.  It doesn’t happen overnight and needs commitment.

First of all, there was a ‘brainstorm’ session where a supposed breakthrough happened about the feature that was to be built but I wasn’t at that meeting and for some odd reason nobody actually took down the minutes.  In lieu of that, I had the stakeholder, product owner and all team members write down their interpretation of what that breakthrough was as it related to the business problem and the agreed upon solution.

Each person read their selections aloud and then the team voted on whether or not they strongly agreed, somewhat agreed or didn’t agree at all.  To make a long story short, everybody wrote basically the same thing and they all agreed on what the value of the feature was and how they planned on implementing it at a high level.

I didn’t plan it that way, but we ended up walking through a story writing session using the same method I actually wanted to do a lunch and learn about.

What did we learn?

1. Write down notes at all meetings.  I usually facilitate all meetings since I’m the scrum master and resident anal personality
2. Do rough sketches of designs
3. Enforce timeboxing
4. The product owner doesn’t need to work in a silo, the team can help in story writing sessions to make sure everything is clear
5. Most importantly, understand the business value.  That is the key

I wanted to wait until the sprint was over to post an update and I’m happy to report that the development for that feature was bang on.  It was actually one of the best practices of leveraging the Scrum practice we’ve used since I started.  The team understood the business value and executed the feature (which the goal was to show a proof-of-concept only) and most importantly a team member reeled in a couple of discussions to keep the story on track while the Scrum Master was dead. Well, dead to the sprint while being re-assigned on another short project.
I’m very pleased with how it all worked out in the end and we have more work to do to get this right.

Retrospectives are a great way to let problems rise to the surface quickly and there should be lengthly discussion and conflict in a retrospective meeting otherwise what’s the point?   It’s the job of the Scrum Master to get this stuff out in the open for discussion.  Given the chance, people will always do the right thing more often than not but a good technique I like to use is the ’5 whys’.    Keep asking”why” to widdle the complaint down to what the REAL problem is.

Obviously some Team members will see this as being told “you are wrong”, and that’s fine.  It’s more important to figure out what the problem is and whether or not Scrum exposed this problem, caused it or had nothing to do with it.  If an organization or team can implement a truthful and open culture, it will be successful.

http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland