Project Management

Home / Blogs / The Reluctant Agilist /

The Reluctant Agilist

About this Blog

RSS

Categories

Date

newer posts

older posts

Book Review: The Scrum Field Guide: Practical Advice For Your First Year

Categories: Agile Transition, Agile Practice, lacey, mitch lacey, field guide, scrum field guide, Scrum

Written by Mitch Lacey, published by Addison-Wesley Professional as part of their Agile Software Development Series)

One of the things that is difficult about taking a Certified Scrum Master or Certified Product Owner classes is that to a large extent, the material looks at Scrum in a state that is (for many) based on an ideal they may never reach. Once students leave the class and go back to work, the number of obstacles they face in the struggle towards Agile transformation can be a daunting thing to overcome. If they are brave enough to take up the challenge, they soon bang up against the fact that when they try to apply Scrum in the wild, what they end up facing may not sync up so well with what was taught in class.

Enter Mitch Lacey’s new book: The Scrum Field Guide:Practical Advice For Your First Year. The Field Guide picks up where the classes leave off and addresses some of the real world issues that people face when they go back to their workplace and start trying to implement Scrum and Agile. In a narrative that is unassuming and easy to read, Mitch Lacey shares stories, his own experiences, and advice from other expert sources on how to actually get Scrum up and running and producing results. The book covers some of the most common questions that come up during implementation like:

When we don’t know what our velocity is, what do we tell our stakeholders we can commit to?

What if you have to play two roles at once?

How do you deal with team members that are only needed for brief, very specific types of work?

How is Scrum Master a full time job and how to you convince others of that?

The cases are presented through stories that set up the different situations. Lacey then draws on his own experiences leading and coaching Agile teams to explore the different options and offer his recommendations.

The book also includes a “First Aid” section for those who are trying to solve very specific issues with things like “Running a Productive Daily Standup Meeting” and dealing with some of the cultural challenges that are part of Agile Transformation.

While it is called the Scrum Field Guide, the book is not just about Scrum. Lacey introduces his own practice of Agile by saying that for him, one of the keys to getting Scrum to work has been pairing it with Extreme Programming. Throughout the book, Lacey introduces XP practices where he has seen them effectively utilized with Scrum.

While the book does include information on the actual Scrum Framework (in the Appendix) it is really designed to work best for folks who have a bit of experience in using Scrum and are seeing various issues, or “smells” as they are often called, creep up.

There are a lot of books out there that are aimed at clarifying what the Scrum Framework is. If you have clarity on what Scrum is supposed to be, and need a resource to help you make it work, The Scrum Field Guide will be a great addition to your tool belt. The title of the book indicates that this book is intended for people who are in their first year of doing Scrum. I’ve been working with Scrum for many years now and I’m also a Certified Scrum Trainer. I still found a lot of valuable information in this book and expect it is something I’ll be referencing in the future when I’m coaching.

Important Links:

Scrum Field Guide on Amazon

MitchLacey.com

@mglacey

Posted on: May 17, 2012 12:10 PM | Permalink | Comments (1)

Distributed Agile Teams White Paper Review

Categories: Agile Transition, Agile Practice, Waterfall, Scrum

ProjectsatWork has published a study called DistributedAgile Teams: Achieving the Benefits. The report was put together by Elizabeth Harrin (@PM4Girls), who is the author of the website A Girls Guide to Project Management. The results of the research cover a lot of ground with respect to what makes distributed Agile projects work and what can contribute to their failure. The report is very insightful and definitely worth the time it takes to read. While some of the findings may seem like common sense, knowledge workers in the IT space (myself definitely included) seem to possess a remarkable capacity for periodic loss of grip to that tether.

My favorite part comes at the very end during the summary of recommendations. Number One on the list is:

Don’t act like your project is co-located – pay the tax for distribution.

This is one of the most simple things that so many of us forget when we are working at a distance. I believe this applies whether you are working down the hall from someone, or across the globe… there is a price that has to be paid when you are not sitting in the same room. With the transparency that Agile offers, this tax becomes far more obvious. There is no doubt that distributed teams provide a number of benefits, but those benefits come at a cost. The reason (IMHO) so many people struggle so much with distributed is that they keep thinking that the ride is free ... which it theoretically could be… unless you actually want it to work.

Posted on: April 24, 2012 11:10 AM | Permalink | Comments (0)

How Much Do We Actually, Really, Totally Need To Do?

Categories: Agile Transition, Agile Practice, Waterfall, Scrum

When I am teaching CSM classes one of the commonly asked questions usually doesn’t show up until almost the very end. When it does, it comes disguised in various explanations and wrapped in deeply detailed back story. In the end, it always boils down to the same question… “How much of this do I actually have to do?”

What strikes me as ironic is it always seems to come at the end of a 2 or 3 day class where we have spent the time discussing an approach to work that is more lightweight than has been used in the past. So, we’ve removed all the extraneous process, lots of the burdensome paperwork and a kitchen sink’s worth of other stuff but the question is still centered around on defining the bare minimum (of the less burdensome process) that must be done.

If the person asking the question is specifically concerned about reaching a state of Agile Nirvana-ness, or works for a company that awards gold stars for Agility, my recommendation would be apply no less than the amount of <methodology or framework of choice> as is required to deliver working product. This is one of the primary way we measure success in Agile. But most organizations do not give out a prize for being “TOTALLY AGILE”. And at the end of the day, the job is to deliver something that works, which can improve the company’s financial position in one way or another. In order to reach that goal, one must apply no less than the amount of <methodology or framework of choice> as is takes to reach that state.

But for many of us, especially those trained in traditional project management, we need a line in the sand. We want something helps us know when we are fighting for the Empire or the Rebel Alliance. (One more reason we should all be issued orange jump suits when we take CSM training.)

There are specific elements in the Scrum framework that (IMHO) when left out result in the practice of something which is possibly Agile, but no longer Scrum. However, my list is based on my own personal understanding of what SCRUM. This begins with what is defined in the Scrum Guide (and related documentation) and is then filtered through my own empirical approach and experiences. I’m quite sure solid arguments can be made to dispute each item I would include (or not include) on that list of what is required to do Scrum.

In my own personal practice of Scrum, there are two parts to the answer. The first part of the answer is that each person involved needs to apply no less than the amount required to complete work that can drive revenue. The second part if that in order to truly see the benefits that Scrum (or any Agile practice can provide), I have learned that it is best to start as close to a pure version or the practice as the individual’s organization can tolerate. Each iteration offers an opportunity to plan-do-check-act over and over again. Each time we go through those steps we should making adjustments until an optimal practice of Scrum emerges. Once this optimal practice does emerge, they must never stop finding ways to break it and make it better.

What I am more curious about is what drives the desire to find the bare minimum of the newer, more lightweight process. My expectation is that it stems from a perception that Scrum would be difficult to implement within the context of whatever waterfall-esque process is currently in place. This could easily lead to the question of how much can we leave out and still technically call it Scrum. But again, at the end of the day, bonuses are rarely awarded based on Scrum purity. And there are, unfortunately, far too many organizations, teams and individuals out there who have jettisoned all but the vocabulary and still feel comfortable calling it Scrum.

Posted on: February 17, 2012 02:23 PM | Permalink | Comments (4)

Breaking the Sprint (Part 1)

Categories: Agile Practice, Scrum

One of the main concepts in Scrum is the idea that when a team commits to getting the top prioritized work to a potentially shippable state by the end of a sprint, that they be allowed to make good on that promise. This is one of the core points at which trust is developed. The organization can begin to trust that the team will deliver as promised and the team can begin to trust that the organization does actually know what its’ top priorities are, and is able to stay focused on them long enough to allow the team to deliver on their commitment.

In theory, this sounds very simple, but for many organizations, the tempting lure of a new opportunity that must be started “RIGHT NOW” is tough to resist. Many organizations see their position in the marketplace as demanding the ability to respond at a moment’s notice to changes in the marketplace. Many of them consider their ability to do this a hallmark of their own agility. Unfortunately, it probably falls closer to a hallmark of their organizational ADD.

When an organization interferes with a team’s commitment once it has been made, it is called breaking the sprint or abnormal termination.

Look! A Squirrell!

For a framework like Scrum to work, there has to be trust. The trust in Scrum is predicated on the various players making promises and sticking to them. For the organization with ADD, their inability to maintain focus on top priorities for a period of time as short as two weeks can be far more devastating than they realize. What’s worse is that the longer this lack of trust remains, the harder it becomes to understand what happens when you violate the trust.

An Example

The Organization considers itself very Agile. It has a market reaction response time of less than ½ day. This means that within a 4-hour period, The Organization has a defined approach of stopping all its’ people from working on their various projects and uniting behind whatever new effort has reached a point of criticality. The Organization has been trying to do Scrum, but Scrum hasn’t been working because The Team can’t finish their work in a sprint and can’t even provide decent estimates as to how long things will take. The Organization believes that if The Team got better at estimating, and making good on their commitment, then The Organization would not have to constantly interrupt them. As it stands now, The Organization can’t wait until the end of the sprint to introduce new work because The Team can’t even tell when the work will be done.

In the above scenario, The Organization has a lot of frustrations with the team not being able to finish work or forecast how long it will take. This is totally understandable. Sadly, The Organization doesn’t see that it is actually the cause of the things it is complaining about.

The Breakdown

In this scenario, regardless of where the breakdown began, what is in play is a consistent, pervasive dysfunction where The Team commits to work it cannot complete. This is in part due to the fact that they don’t expect to be allowed to meet their commitment because The Organization has (through it’s behavior) set an expectation that they will interrupt the sprint and ask the team to re-plan around new work. For the team who is expecting the interruption, there is little chance that they will be able to become completely invested in meeting their commitment since no amount of effort on their part will make it happen anyway.

The second cause for this issue is that the team does not understand it’s own velocity. It doesn’t understand its’ velocity because it never meets its’ commitments. Without velocity, it can’t accurately plan work into a sprint or understand when a particular set of work will be completed.

If The Organization were able to hold off until the end of the sprint and allow The TEAM to meet their commitments, The Team would be able to to understand its’ velocity. If they understood this, they could determine how long things would take and provide The Organization with the forecasting information they need.

Each time The Organization breaks the sprint and has the team reorganize around new work after a commitment has been made, it steps on The Team’s ability to deliver and earn the trust of The Organization. In order to reform the trust, The Organization is going to have to stop interrupting the team and allow them to complete their work. Only then will they get the level of predictability they are looking for.

Posted on: November 21, 2011 10:03 AM | Permalink | Comments (2)

Sprint Retrospectives

Categories: Agile Transition, Agile Practice, PMBOK, Scrum

If you are accustomed to working within the context of a traditional approach to managing projects you are probably familiar with the idea of doing a post mortem, or review at the end of a project. The objective of this meeting (or set of meetings) is to examine what has taken place and find a way to generate lessons learned which could be used to improve future efforts. In theory, this sounds like a great idea. In practice, however, there are two problems with this approach. First, they are rarely done with the regularity, or rigor required for them to truly add value. More often than not, team members are reassigned and send off to work on new projects before the project review can be conducted. Second, when project reviews are conducted, it is typically to focus only on the things that went wrong. Unfortunately, this often turns into a finger pointing session that does little to recognize the things that went right, and often is more centered around hanging blame on individuals than on determining the practices or processes that allowed the trouble to start in the first place. There are, to be sure, exceptions to the above, but in a traditional model skipping this critical step is far too common.

Repeatedly taking the time to examine how things are going is something that is baked right into an Agile approach. Scrum, for example, is defined as being built on “three legs”: transparency, inspection, and adaptation. If you are practicing Scrum, each Sprint includes the Sprint Retrospective, a “ceremony” where the team meets privately to inspect how they are working and to determine what steps they need to take in order to improve during the next Sprint. While a disciplined traditional approach may include a review at the end of each project (or ideally, the end of each phase), in Scrum, this happens every 2-4 weeks. It is the last official thing a team does during each Sprint.

The Scrum framework offers a more lightweight approach than you’ll have under a more traditional methodology like the one defined in PMI’s Guide to the Project Management Body of Knowledge (PMBOK). Because Scrum has removed so much of the process overhead, one of the things that teams come to depend on is the cadence of Scrum. We begin each Sprint with our Sprint Planning meeting; we hold a Daily Standup (or Scrum) meeting each day (at the same time in the same place); we hold a Demo (or Review) meeting with the stakeholders at the end of the Sprint and we follow that up with the Sprint Retrospective. Each of these practices provides opportunities to inspect and adapt, but it is the Retrospective meeting where the team comes together privately to exhale at the end of the Sprint and work out how they, as a unit, can become more effective.

Another interesting aspect of the Sprint Retrospective is the way the meeting is conducted. Teams will often start by focusing the positives and identifying what went right during the Sprint. Even if the Sprint did not go well, there is always something positive that can be gleaned from it. When the team talks about what could have gone better, the goal is to offer constructive criticism geared towards enabling them to function better as a unit. The subtle shift in from focus on “you” to “we” is a very important cultural change for those of us making the switch from a traditional approach. Before the Sprint Retrospective ends, the team will come up with an action plan for the next Sprint so that they can do more of the good things they’ve identified and take steps to correct some of the things that did not go as well as they could have.

If you are new to Agile, it may seem unnecessary to hold reviews with the frequency called for by Scrum - especially if things appear to be going well. Many rely on the old adage, “if it ain’t broke, don’t fix it”. The problem with that approach is that it becomes far to easy to overlook things until a time when they are so clearly broken, that there is no way back. If we are always inspecting and adapting, we are far more likely to catch things while we still have the ability to make any necessary adjustments.

If you are interested in learning more about Retrospectives, there is a great book by Esther Derby and Diana Larsen called Agile Retrospectives: Making Good Teams Great.

Posted on: September 14, 2011 10:45 AM | Permalink | Comments (0)

newer posts

older posts

The Reluctant Agilist

About this Blog

RSS

Recent Posts

Categories

Date

Book Review: The Scrum Field Guide: Practical Advice For Your First Year Categories: Agile Transition, Agile Practice, lacey, mitch lacey, field guide, scrum field guide, Scrum

Distributed Agile Teams White Paper Review Categories: Agile Transition, Agile Practice, Waterfall, Scrum

How Much Do We Actually, Really, Totally Need To Do? Categories: Agile Transition, Agile Practice, Waterfall, Scrum

Breaking the Sprint (Part 1) Categories: Agile Practice, Scrum

Sprint Retrospectives Categories: Agile Transition, Agile Practice, PMBOK, Scrum

Sponsors

Vendor Events

Guessing is not a strategy: How to build decision velocity with AI and real-time data

Newsletters

Book Review: The Scrum Field Guide: Practical Advice For Your First Year

Categories: Agile Transition, Agile Practice, lacey, mitch lacey, field guide, scrum field guide, Scrum

Distributed Agile Teams White Paper Review

Categories: Agile Transition, Agile Practice, Waterfall, Scrum

How Much Do We Actually, Really, Totally Need To Do?

Categories: Agile Transition, Agile Practice, Waterfall, Scrum

Breaking the Sprint (Part 1)

Categories: Agile Practice, Scrum

Sprint Retrospectives

Categories: Agile Transition, Agile Practice, PMBOK, Scrum