Author: Robert Galen

Agile Release Planning End to End Project Envisioning Part 2

Written by Robert Galen on April 8, 2014. Posted in Articles. 8 Comments on Agile Release Planning End to End Project Envisioning Part 2

Continuing on with end-to-end planning techniques within agile contexts –

Crystal Blitz Planning

Alistair Cockburn’s Crystal method gets very little attention in the agile community. In many ways it’s one of the forgotten agile methodologies. So it hasn’t been well received as a method, but I like to “mine” Crystal for techniques and ideas to supplement my agile methods coaching. The notion of a “Walking Skeleton” from Crystal is useful in speaking about emergent software architecture. And in the release planning area, Crystal’s notion of Blitz Planning is useful as well.

The best description is in the Crystal Clear book. Blitz Planning is a multi-part, team-based approach to pull together a high-level view to all of the work (and supporting work) to deliver on a projects goals. It doesn’t prescribe a specific release interval (period, or set # of sprints). Instead it lets the scope of work drive the # of iterations in the Blitz Plan. That and the scope of work related to creating production-ready product.

User Story Mapping

Jeff Patten is the creator of this practice. David Hussman and he have collaborated on a refined the practice. It’s an exception to this list in that it’s not entirely a planning approach. It sort of is and it isn’t. The primary focus is on User Stories graphically not as a functional or requirement perspective, but as how the User will see, feel and use the system as it develops. I would consider it a UX technique.

It lays out your stories in 4 levels:

Backbone – stories focused on major functional areas of customer usage
Walking Skeleton Tasks – smaller stories that support the Backbone; a minimalist view to functional requirements
Sub Tasks & Task Details – smaller stories that support the Walking Skeleton or finer grained understand (for example, acceptance criteria).
Infrastructure – what I might call “glue stories” that provide infrastructure and support for the Walking Skeleton. Typically dependencies.

I actually recommend doing User Story Mapping as an adjunct to Release Planning; usually before the planning. So the sequence becomes: Backlog creation & Grooming -> Story Mapping -> Release Planning. This way you’re putting customer problem solving and functional usage before actually planning iterative and release deliverables.

SAFe – Release Train Planning

A relatively recent development in the agile community is a strong focus on Enterprise-level, scalability models. Dean Leffingwell has introduced the Scaled Agile Framework or SAFe. Scott Ambler has introduced Disciplined Agile Delivery or DAD. Craig Larman and Bas Vodde have co-authored two books and are working on a third that is focused on “agile at scale” techniques and practices. Ken Schwaber is starting to talk about Agility Path and Enterprise Scrum on the Scrum.org site. And there are still others that are getting into this space.

There has always been the venerable Scrum of Scrums model. It often gets overlooked because there is so little tactical guidance on how to effectively implement it. One reference for it is in my Software Product Ownership book.

Dean has long described a release model called the Release Train. It predates all of this enterprise-level hoopla and was simply an iterative view towards how to build and guide a series of iterations or sprints into a “shippable product increment” instead of a “potentially shippable product increment”. It turns out that there is usually quite a lot of preparation and work to release something that isn’t all about deliver user stories or features.
SAFe describes a 2-day Release Planning meeting that aligns with the Release Train and a Potentially Shippable Increment (PSI)

Agile Project Chartering

If you were to ask me – where do these sorts of techniques fit within agile project management, I would probably say this:
First, for straightforward or single team agile projects, many of these longer term planning activities are unnecessary. The regular planning activities associated with your agile methodology will take care of things. But, and I mean but, if you’re working on

A distributed project or a partially or full outsourced project
A complex project
A multi-team project
A project with many dependencies
A project with Waterfall dependencies
A software plus hardware project
A project within a regulated industry
A project with large scale testing requirements
A risky project
A project that required some upfront design decisions

Then you might want to strongly consider these techniques. And not simply as part of some standalone effort, please no, but instead as part of CHARTERING your project. Much of this early, release level planning occurs during traditional project chartering phases of projects.

The book LiftOff by Larson & Nies covers quite a few approaches to agile chartering.

And you might want to read a more “traditional” book on software project management and chartering to gain a feel for the depth and breadth of solid chartering, for example, Wysocki’s book. Starting agile projects off is something that many agile teams skip—preferring to simply “dive in” and start sprinting. It’s often a huge mistake.

Wrapping Up

I hope that this “walk” through a bunch or practices has helped you to understand that there is available wisdom, in some depth and breadth, surrounding agile planning. Sometimes I think we get to be so “agile” in our thinking that we forget some of the practices we’ve learned over the years and how useful they are in specific contexts. So I hope I’ve inspired you to do some research and study and to consider agile project chartering and release planning as one of the tools that should be in your agile toolbox.

Between us, I rarely find a company or project context nowadays that doesn’t support doing a little chartering and release planning. While I might scale it down, not doing it is normally not an option to me.
Finally, I just noticed the other day that David Hussman’s videos are no longer being sold on the Pragmatic Bookshelf. These were professionally recorded sessions that at one point he was selling. Not sure what happened, but now they’re available for free on his website. What a remarkable gift for the agile community.

David Hussman’s video’s cover quite a few of these areas: http://devjam.com/2013/07/12/cutting-an-agile-groove-overview/ Highly Recommended!

Stay agile my friends,
Bob,

Don’t forget to leave your comments below.

* – the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia. http://en.wikipedia.org/wiki/File:Chasse_a_courre.jpg

References

Agile Release Planning End-to-End Project Envisioning, Part-1

Written by Robert Galen on March 12, 2014. Posted in Articles. 11 Comments on Agile Release Planning End-to-End Project Envisioning, Part-1

galen March12 It was around 2004-2006 that I started to connect the dots between some traditional, but low-fidelity, planning techniques I’d been using and agile, or XP at the time, release planning techniques. I think it was the Kent Beck & Martin Fowler book that explored agile planning beyond the individual iteration.

Fast forward to today, and there’s a tremendous amount of discussion (and confusion) as to how release-level planning fits within agile methods and teams. I’m a Certified Scrum Coach (CSC) and as of the Summer of 2013, there’s still a lot of discussion in that community surrounding it. A good part of that is whether it fits into the definition of “Core Scrum” or not. I actually don’t think it does. Another part of the discussion is how it might map to Backlog Grooming, since there is estimation and workflow elaboration in grooming. Again, in my view, it’s not a grooming practice, but having a well-groomed Product Backlog does help your release planning.

I also think context matters when we’re talking about it. For example, if we’re leveraging Scrum or agile methods in a very small, start-up context, then I don’t know if Release Planning is all that useful. The teams are probably learning and pivoting frequently, so sprint-x-sprint planning is probably the right level as they triangulate towards their goals.

But there is a wide variety of contexts where sprint-at-a-time look ahead and planning is too simplistic of a view. Whether we like it or not, many organizations need some sort of release level planning and predictability. It’s just too hard to figure it out as you go. But at the same time, the organization needs to understand that these are flexible plans that will adjust as discovery and progress is made. They simply need a roadmap-level or high-level view to where the team is going and what they’re planning on delivering.

What are the key focus points of Release Planning?

It gives the team a sense of the x-team and x-backlog interactions (dependencies) that need to be negotiated to deliver a product. This view is broad—from “release concept” to “released in production” timeframes.
It provides a tracking mechanism, establishing a baseline view if you will, so that every iteration or sprint can be compared against planned progress. Often this includes a “release level” burndown chart and an overarching set of release criteria or goals.
The thing I like most about leveraging release-level planning is the vision it provides everyone. It’s sort of akin to an architectural diagram at a project level. It’s the big picture and it gets everyone on the same page towards common release goals and functional targets.

In other words: you have directional awareness and a game plan before you—Let Loose the Hounds.

Release Planning – History and Approaches

It turns out that folks have been doing iterative release planning since before the start of the Agile Methods. There’s quite a bit of commonality and overlap in the techniques. I view that as underscoring the value it has for the team. I thought it might be useful to highlight some of the techniques and provide follow-up references for each—sort of a compendium of approaches. I hope you find it useful.

Cards-on-a-Wall

Dwayne Phillips published a Software Project Manager’s Handbook in 1998. One of the techniques he spoke to was a “Cards on a Wall” planning technique. It was a low-fidelity technique using 3×5 cards to represent all of the work related to a software project. You would stick the cards to a wall and move them around to represent the workflow. You would identify related work (dependencies) and often could use string to talk about critical paths within the flow.

It leveraged a whole-team view, so everyone (from architect to DevOps; leader to programmer; and developer to tester) participated in the session. It was truly and effort to get the Wisdom of the Crowd into a representative release plan.

I remember using the technique to plan a 100 person software project at Bell & Howell in 1998-99. It worked beautifully and the project came in on-time. The most effective part of the technique was the “shared view” it created for the team for the entire project.

References

TSP Launch Planning

Many years ago, also while at Bell & Howell I introduced the Personal Software Process to our teams. A few years after that, the SEI introduced the TSP or Team Software Process. While the PSP was focused on the individual developer, bringing rigor to their individual work, TSP looked at the team dynamics of delivering software.

The Team Software Process has a 4-day launch process defined that is a whole team approach to moving from a requirement list to a detailed, end-to-end plan. The final part of the launch is negotiating (resolving) the plans

References

XP & Scrum Release Planning

I think many of us forget that the Extreme Programming folks had the notion of Release Planning as an adjunct to Iteration Planning. There’s also quite a bit of discussion in the Scrum community surrounding this notion. The two often “look the same” in implementation. Joe Little has written a nice “booklet” that describes his approach for it within Scrum contexts.

I think too many folks get caught up in whether it’s a “Core Scrum” practice and they lose sight that in a wide variety of contexts it can be a critical practice to guide projects as-scale. The envisioning, planning, tracking, and transparency aspects can be crucial for the team and leadership alike.

References

We’ll continue in the next post with a few additional planning techniques and then wrap things up. My hope is that you find these tools, techniques and thinking models useful in some of your agile contexts.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

* – the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia. http://en.wikipedia.org/wiki/File:Chasse_a_courre.jpg

Google’s 20% Time…Sadly it is Gone!

Written by Robert Galen on February 26, 2014. Posted in Articles. 4 Comments on Google’s 204 Time…Sadly it is Gone!

galenFeb26 A few months ago I saw an article about Google having decided to drop its 20% time for its teams. If you’ve been living under a rock, this is one of the most referenced (and admired practices) at Google. In essence, every engineer was allowed to spend/invest 20% of their work time on project(s) that interested them. It was a creativity and innovation incubator of sorts. Teams would surround the “best ideas” and work on this with 20% time. As experiments would show merit, they might make it into the core products or leveraged as a new tool, technique, or method. And no, 20% time did not mean that employees worked 120% of the requisite time. It was an 80/20 split and not intended as a project schedule accelerator.

Now they’ve changed policies. Innovation is being focused more on specific teams working in labs, so more centralized. And 20% time is now jokingly referred to as 120% time as Google’s official policy hasn’t been to “remove it”, just to move it to discretionary—in each employees “spare time”. It’s too bad really, because this policy was truly inspirational to many companies.

Inspiration

Google 20% time inspired a generation of software companies, particularly those leveraging agile methods. I get around to quite a few conferences and over the years folks frequently talked about “their variations” of 20% time, how they implemented it, and the impact it had to their business. I don’t recall a single conversation where a 20% time variant caused significant angst on the part of a company.

One of my frequent examples of 20% time’s influence is Atlassian. They’re one of my favorite companies, first because they product some wonderful tools that are simple and just plain work. I’ve been a long time user of their products such as Jira & Greenhopper for agile project management. Sure they are not the most feature rich, enterprise level agile management tools on the planet, but they simply work. But enough of the commercial; the other reason I admire Atlassian is that they are an agile shop. They eat their own dog food or practice what they preach.

They have a notion of FedEx Days and 20% time. Here’s a video on the topic as well. And here’s an interesting quote from Ben Tsai’s blog on the topic:

This is an exercise in trust. More important than the specific number of hours spent on side projects versus billable projects is the idea that the company has faith in its engineers to do innovative things. Its recognizing innovation can’t be mandated and is not guaranteed, but we can create an environment that nurtures innovators—where experimenting is welcomed and failing is OK. Giving engineer’s autonomy is a powerful motivator

I actually agree with Ben’s insight. At the end of the day, I think 20% time IS about trust. Oh, we’ll talk a good game about being behind the competitive curve, or behind schedule, or lean and mean; but truly if you’re building software – you need to innovate. And trusting your team is the way to go, but so few “get” that fact.

Oh well. Let’s switch gears and talk about a real-world example from my own experience. I hope it helps by providing a crisp example of what implementing 20% time might “look like”.

iContact’s – Innovation Days or iDays

I was the Director of Software Development at iContact from 2009 to 2012. We were a solid, perhaps even high-performing Agile / Scrum shop, and were consistently looking for ways to improve. Taking a page from the Google and Atlassian playbooks, we created something called Innovation Days or iDays within our technology organization. The organization encompassed about 100 engineers.

We ran iDays for over two years, so it evolved during that time. What I thought I’d do in this article is share some of the details of iDays as a way of helping you understand and potentially implement a similar practice.

Setup

We decided that there needed to be a “Cruise Director” for iDays. Someone in a management role to keep it going, provide leadership support, and generally provide guidance. The role fell to one of our managers and he did a great job of “guiding” its evolution over the two years. Consider this role to somewhat akin to being a Scrum Master for iDays.
We didn’t want iDays to focus on the individual, nor on existing teams. We had the notion that iDays would be:
- Driven by ideas;
- Ideas would draw a team to them based on the potential & value of the idea;
- And a team would form around the idea. It minimally needed to be cross-functional, so developer(s) and tester(s) needed to “sign-up” for the idea. And each idea needed a champion or sponsor; perhaps call them a Product Owner.
We chose to hold iDays at the end of a release sequence or Release Train. In our case, that was every 9-10 weeks. We would focus 2-3 days at the end of the week between releases for iDays. Nothing else was scheduled during those days, as we wanted total immersion & focus on the part of the teams. Usually it would be a Thursday – Friday or Wednesday – Friday sequence. We would also provide lunches and snacks during each day and over the weekend if the teams wanted it.
Not all iDays teams produced code, but all produced “something”. If they were focused towards potential product-level code ideas, then they would be responsible for environment setup and ensuring that the work didn’t impact the ongoing production or maintenance code branches. In other words, there was an organizational agreement that iDays projects would not negatively impact our customers. They needed to be “Done” within the context of the goal.

Dynamics

The iDays Scrum Master would start sending reminders out for team ideation 2-3-4 weeks before the end of the release. He would setup a wiki page (Confluence of course) for teams to capture their ideas and natural team formation. This would be the place where ideas were vetted. These could be new ideas or continuing ideas from the last iDays. We simply wanted full transparency for ideas leading up to iDays.
Not all ideas were “worthy”. Some didn’t collect a cross-functional team. Still others were simply too large to “fit” into iDays and still product something valuable and demonstrable. Still others didn’t align with our customers or business goals. While filtering was very lightweight, the Scrum Master also served as an iDays project vetting agent to ensure we were staying focused and on-point. So ideas, very much like User Stories, were vetted, clarified, broken down, and refined during the weeks leading up to each iDays.
Once iDays started, there was tremendous focus in the building. The small teams focused on getting something “done”. We didn’t have a clear Definition of Done for the iDays projects, but the overriding goal was—something demonstrable that didn’t “mess up” Production. It seemed to be enough. The other thing that seemed to keep the teams focused was the demo. Everyone new that they would be showing “working code” on Monday morning, so that kept the focus and the pressure on.
We intentionally scheduled iDays to be at the end of a week. While we didn’t ask the teams to work over the weekend, if often happened. We sort of expected it as their enthusiasm increased with the fruition of their idea. We wanted to allow for as much immersion around each idea as possible.
On Monday morning, an iDays Review was conducted. We held it very much like we did our Sprint Reviews. It was a “whole company” event, we had an agenda that was published, and each team took a turn at demonstrating their ideas. A typical iDays might involve ~10 or more teams and the review might take 1-2 hours for all of the teams. Over time, it became such an “event” that our entire C-level and Senior leadership teams attended.
We asked the entire organization to vote on the Top 3 innovative projects they saw from iDays. Everyone got a vote, even the teams. This encouraged attendance at the review. It also fostered engagement. But ultimately it was fun and created some healthy competition amongst the teams. “Winning” an iDays project was a badge of honor within the technology teams.

Beyond the top 3, every iDays project was recognized and appreciated. As far as I was concerned, everyone was valuable.
One final point. After about 2 years of doing iDays, I kept track of how many of the “ideas” made it into our product(s). Over 60% of our iDays ideas made it either (1) into the hands of our customers or (2) directly into the day-to-day efforts to put product into the hands of our customers.

Lessons Learned

Here is a short list of the high-impact lessons we learned while using our iDays model:

Have a champion or guide;
Have a cross-functional, cross-team focus;
Let “ideas” drive, but not everything is ‘worthy’;
Setup a specific time in your work tempo;
Focused teams with no interruptions;
Demo, celebrate, valuate, and celebrate again;
Reflect & iterate;
You’ll hit rocky patches, but stay committed;
Trust your teams!

Wrapping Up

How do you measure the success of a program like this? I know, I know, it’s hard.

We focused on morale at iContact quite a bit. Did the teams gain energy and engagement as a result? Did the entire organization get a lift? Did it increase our creativity and thinking? Those measures, in and of themselves, seemed worth it to us. It also helped our teamwork: cross-team collaboration, focus, and customer awareness.

We also measured which “ideas” made it into “Production”. As I said, during the course of iDays, over 60% of the ideas made it. It was about 64% as I recall. We took great pride in this figure because of the impact it had to our clients.

The final measure, one that I personally took a lot of pride in was from our leadership team. One day our CEO came down to the technical leadership team and asked a very interesting question. He said:

Why can’t we add more days to iDays? I’m thinking of 4-5 days. We get such incredible results now, I wonder what the additional time would do?

After that statement, I think our measures were essentially…done 😉

As always, thanks for listening,
Bob.

Don`t forget to leave your comments below.

The Agile Project Manager: Can Agile Teams get “Burned Out”?

Written by Robert Galen on February 5, 2014. Posted in Articles. 10 Comments on The Agile Project Manager: Can Agile Teams get “Burned Out”?

My My, Hey Hey (Out Of The Blue)

My my, hey hey

Rock and roll is here to stay

It’s better to burn out

Than to fade away

My my, hey hey.

–Neil Young

One of the core principles of agility is the notion of “sustainable pace”. It originated in the Extreme Programming community. Initially, in v1 of the XP book, it was defined or framed by the principle of a 40 hour work week.

I vividly recall managers at the time railing (no ruby intended) against the notion as a clear example that these agile maniacs were out of touch with business reality, out of control, and looking for an easy road at work. What could possibly be next—working from home?

In the second edition of XP, Kent Beck softened the message a bit and dropped the (n) hours recommendation. Nonetheless and thankfully, the notion of sustainable pace has remained as one of the core agile principles. Although there does appear to be an increasing de-emphasis of it within today’s agile teams.

Back to the Title Question

Can agile teams, solid agile teams who are high-performing for that matter, can they “burnout”? I believe the answer is yes. In fact, I’ve seen the phenomenon occur quite frequently. One example are teams who schedule their sprints sequentially or back-to-back, without a pause or break. For example, every other Monday they’re starting a sprint and every other Friday they’re closing a sprint, with not a break in between and for months (or a year or more) on end.

I often see these teams simply needing a break of some sort, but they’ve succumbed to the tyranny of agile iterations and don’t think it’s possible to “take a break”. Another driver is they’re too focused on reducing lean waste, and again, they look at any down time or slack time as being wasteful.

Somehow I think we’ve overly focused on iteratively being agile and on reducing waste that we’ve forgotten that we’re dealing with people in our teams. And people can get exhausted and often can use a break to recharge their batteries. Back to the Neil Young lyric, I don’t think it’s better to burn out, especially not in a continuous improvement and delivery model.

“Burn Out” Indicators

Next I want to share thoughts around burnout indicators. At the same time, I want to remain cautious in giving you a definitive list of indicators, as everything should be interpreted in the context of your culture and team dynamics. But knowing what to look for is often helpful in catching early stage burnout before it becomes systemic. Here are a few signs of burnout:

Excessive overtime; becoming the norm with long term duration;
Rising mistakes: bugs, poor design choices, and hurried implementations;
Rising temperatures, increasing levels of team stress and conflict;
Lack of humor / fun, team is too focused and lost any playfulness;
Lack of refactoring or quality investments;
Excessive negotiation (or avoidance) of your Done-Ness, rushing at the ends of Sprints;
Excessive time-off, high levels of team stress seeping into home;
Not taking time off / not taking or cancelling vacations;
Increased paranoia; “they” are after us, we have no choice;
Lack of transparency, honesty, openness, and continuous improvement.

Of course you don’t want to overreact. Hard work, dedication, and engagement are hallmarks of healthy agile teams AND there is certainly “normal and healthy” stress within teams. But here I’m looking beyond healthy reactions and I think you’ll be able to tell the difference.

7 Ideas for Possible “Refreshments”

So if you are suffering from burnout, what are some helpful techniques to refresh and recharge your teams? This is simply a starter list of ideas for you to try or use to brainstorm your own refreshments:

Ask them

My first response would be to ask your teams? Ask how they’re feeling and whether they need a break of some sort. Also, set the stage so that it’s “ok” for the team to ask for a break without feeling wasteful or unprofessional or guilty. Gather their response and sort through what options you might have to support their ideas. There’s nothing better than showing you care, are listening, and are willing to take action on team feedback.

Plan @ 80%

In waterfall teams it’s a fairly common practice to plan teams at 100% of their available time. Sure, you may allocate time for meetings and other diversions, but of the remaining time, you invest it at 100%. I’m going to recommend something you might struggle with, but so be it. Whatever your work capacity is for each individual, ask them to plan their effort at 80% of it no matter what. Not as some vacation factor, but as a slack factor to allow time for simply thinking, considering creative solutions, and to breath a bit. How they use the 20% is totally up to each individual and nobody micromanages it or tries to reduce it under any circumstances. Last time I checked, these are your trusted knowledge workers—so allow them so flex.

Pair more

Pairing can often defuse the pressure on each individual team member. By definition, the pair is sharing workload challenges and more used to asking for help from others. They become more focused on the work and delivering high quality features, rather than the false focus of keeping team members at 100% efficiency. I’m talking about comfortable, non-forced pairing here; as it makes sense within the teams’ Sprint Goals and backlog.
Another byproduct of pairing is reducing single points of knowledge or skill within the team. This allows for more flexibility in the team’s ability to meet the business’ demands and reduces individual stress for key team members.

Plan for a break

I’m, fairly fond of injecting “breaks” within my organizational release tempo. I usually like planning for a “break” during the interval between releases. Yes, I actually will pad time between releases, normally a week or so. Part of the week is for supporting the release. Part is for planning the next release. And a significant part is decompressing and personal time for the teams. Normally, I’ll leave it in each team’s hands to figure out how they’ll make the transition from one release to the next. But they need to factor in some break time for recharging their batteries.

Allow the team to work on their interests

Technical teams are often driven incredibly hard to deliver what the “customer needs”. I sometimes refer to this as feature-itis or 100% feature syndrome. It’s not necessarily bad if done infrequently. But in excess, the team may be unable to complete things that they feel are equally important, for example, extending infrastructure, fixing bugs, or fine-tuning some environmental tooling. I think excellent Product Owners learn how to feed their teams a balance of work—some of which is interesting to them. Allowing the team to occasionally work or immerse on what they want or what they think is important can often help recharge their batteries.

Focus

There can be a tremendous amount of wasted time surrounding the activities of an agile team. This can then lead to stress as a result of trying to compensate for the waste. Reducing meetings, actively facilitating meetings, allowing for more working from home, have the team work in a common space, etc. are ways to increase their focus. Also, don’t be afraid to let folks work alone. The majority of software folks are introverts—so they need some private time for increased productivity, creativity, and ideation. Point being, don’t force too much collaboration.

Go have fun

Get out of the office and do something that the team enjoys; either as a team OR as individuals. I’ve seen some teams focus on gathering together for fun. I’ve also seen teams who realize the commitment folks make to work and go off to spend some special time with their families. And sometimes there’s a combination of the two. As an agile leader, I’ve often provided funds to the team to support whatever activity(s) they come up with. My only stipulation is for them to have fun and get some decompression time.

Wrapping Up

I believe there is a lot of burnout within agile teams today. I think teams are being worked too hard and have too little buffer or slack time to recharge their batteries and their brains. This was true in waterfall teams and led to the coining the term Death March and the associated working patterns of failed projects.

I’m not implying that agile teams should take it easy or not work hard. I actually think that “Agile done well” is a very intense working pattern. Excellent agile teams can even burn out while working consistent “40 hour weeks”, so the hours aren’t the only determinant.

I’ve mentioned the term “slack” several times in this article. I use it with Tom DeMarco in mind and his exploration of slack in the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. The book does a great job of making the argument for allowing/encouraging some “white space” in your organization and team’s time.

What I hope I’ve inspired you to do is be aware of burnout within your agile teams. Look for the indicators and ask your teams about it. Show a willingness to slow down to go faster and to take the occasional break. Sure, you’ll need to trust that your team won’t take advantage of it. But why wouldn’t you trust those wonderful folks you hired anyway?

As always, thanks for listening,

Bob.

Don’t forget to leave your comments below.

SideBar: A Diversion on “Slack”

There are some key points behind the notion of “slack” that speak to the very essence of your leadership style and organizational culture. It’s not simply throwing the team a bone around some extra time. Instead:

It says that you’re not driving your knowledge workers towards 100% efficiency. That you understand that they need slack time to recharge their batteries and refresh their work. That you understand that this leads to more productive team members and higher quality solutions.
It says that you trust your knowledge workers. Their collaboration as a team, their understanding of your goals, and that their work effort is towards meeting company goals and not simply hour targets.
It says that you are looking for and fostering time for innovation and creativity. That your use of these terms are not simply “lip service”, but that you’re willing to put your money where your mouth is. Even when a project is “behind schedule”, you honor your commitments to slack and work with the team on creative adjustments.

The Agile Project Manager – You Can’t Handle the Truth!

Written by Robert Galen on December 11, 2013. Posted in Articles. 10 Comments on The Agile Project Manager – You Can’t Handle the Truth!

http://moviescreenshots.blogspot.com/2008/03/few-good-men-1992.html

One of my favorite movies of all time is A Few Good Men with Jack Nicholson and Tom Cruise. I can picture that highly charged confrontation at the end clearly in my mind. You know the one.

Tom Cruise says—I want the Truth…
And Jack Nicholson leans forward, with that classic look, and says—
You Can’t Handle the Truth!

What a climax to the film. I get chills every time I watch that scene.

I’ve been thinking more and more in my coaching about why leaders and managers often wait too long to ask for agile coaching help. I think it’s a general phenomenon in agile (and non-Agile) teams and organizations, but for the purposes of this article, I want to focus upward—on “them”.

The THEM in this case includes:

C-level leadership
Vice Presidents
Directors
Managers
And even Project Managers

So, I hear you asking. What does the movie A Few Good Men have to do with leadership recognizing their weaknesses when it comes to agile transformation and asking for help? Well, I’m glad you asked. That’s where we’re going next.

Wise words from Ken

I received my CSM (Certified Scrum Master) certification in 2004. Incredibly that’s nearly 10 years ago and I was practicing Scrum for several years before that. I feel like a dinosaur sometimes when it comes to my agile experience (no comments from the peanut gallery please).

I specifically took my class with Ken Schwaber. I remember being underwhelmed at the time with the class, because I had so much experience. But over time, there have been snippets I remember that were quite profound and useful. I’ll share one of them now.

I remember Ken saying that:

Scrum doesn’t cause problems…any problems. It’s simply an Agile Project Management “wrapper” or framework. So, it doesn’t create issues or impediments or problems.

However, what it does do is this. It surfaces those things IF you have them. And it does something more. It surfaces them every day that they’re impacting your projects, progress, team, quality, commitments, etc. I.e., you can’t ignore them.

Or if you try to, they’ll just keep being raised until you resolve or remove them.

Or, and he didn’t say this, until you stop using Scrum or other agile approaches. That’s another way to handle these issues.

After more than 10 years of actively using Scrum and other agile approaches, I wholeheartedly agree with Ken. And as a leader, having held mostly Sr. Manager, VP, and Directors level roles during this time, I even more vehemently agree. If there’s an issue, impediment, risk, problem, fault, nuclear explosion, or whatever potential challenge facing your teams, then you better get ready as a leader, because you may be called on to…gulp…LEAD.

The Truth Is…

I believe many traditional leaders really struggle with “going Agile”. Sure, the speed and quality aspects seem attractive, as does the increase in delivering customer value. But the trade-off is what’s not that palatable. That whole thing of becoming a servant leader and engaging the team can seem daunting. As can the notion of trusting and supporting their teams—empowering them (the team) to tell truth in their estimation and commitments and trusting their judgment.

You have to be on top of your game as an effective leader and be willing to remove issues, impediments and challenges that quite often are system, organization, or political. It’s often risky and it requires courage on the part of the leader. Many of whom struggle to “Handle the Truth”.

Avoiding the Truth

I think there are many ways that leadership tries to avoid the truth. Many of these patterns have their genesis in Waterfall, where deferring or denial can be an effective short term response in projects. Here are a few patterns that you might have seen before:

I don’t see the problem in exactly the same way you do. Please wrap up your problem statement, analysis, and resolution options in an email and send it to me. I’ll study your recommendation(s) and see what I think we should do next.
1. Sometimes known as: simply buying time or opening the door to – analysis paralysis
Don’t bring me problems…bring me solutions; no matter what the challenge!
1. Sometimes known as: not facing reality, pushing ALL problems down towards the team and not wanting to engage with the team. Not being part of the solution.
I really don’t agree that this issue is “Red” and impacting the viability of our delivering on time. I’d rather call it a “Mellow Yellow”, while everyone needs to work harder mitigating the issue.
1. Sometimes known as: I’ve scheduled a vacation and I don’t want this to interrupt my Greek beach experience. My boss doesn’t need to know about it yet.
I know we’re in trouble, but we must add these two additional features to the release. The CEO demanded them and I agreed that we could squeeze them in.
1. Sometimes known as: we have no choice. Our customer is a tyrant and we have to do whatever they say. More often indicative of – I’m afraid of pushing back, trading off, or negotiation. We must say yes.
Everyone, you committed to this project plan in the beginning and I expect you to work as hard and as long as necessary to meet your commitments. No matter what you “discover”. So, let’s get to it!
1. Teams commit to early plans at the point where they know the least. Holding them to every line of code is unfair, unrealistic and cruel. Often there is the “hanging threat” of negative ramifications—project failure, company failure, loss of $$$, loss of job, etc. Truly the “stick” coming into play.
Every Project Manager – I want you to work with the team to scrub the project plan looking for “optimization opportunities”. We’ve got to be able to improve this plan so that the results are doable!
1. Sometimes known as: sick the Project Managers on the team. By looking at the minutia, they will eventually find a way for the project to be achievable (or recovered) on paper. Then it’s the teams’ responsibility to deliver. The devil is in the details…right?
I hear all of your assumptions and contingencies, etc. But we’re going to commit to this plan and deliver 100% of what our customer wants, no matter what…right?
1. Sometimes known as: Since I’m not doing the work, I don’t understand why you can’t make “magic” happen. Or as, this is simply whining to me. Stop whining, and start doing!
If this project team cannot deliver on time, you’ll be forcing me to go to our offshore partners and fund/staff the project there. Those folks know how to suck it up and deliver the goods…
1. This is another popular recent trend—getting teams to compete for work. Fear and threat being the primary strategy here. And it’s rarely the case that the offshore folks can do better, they just don’t complain until the very last moment.
I find the team to be too pessimistic; all I hear is can’t, can’t, can’t. You need to be more “can do” and optimistic. I know you’re bright and capable, so figure out a way to get this done in time.
1. Sometimes not delivering 100% or negotiating or saying no are not negative reactions. They’re realistic and mature reactions. They’re based on the reality of the situation. And solid leaders need to be ready to hear “Bad News” and then react effectively.
I’m simply too busy to get involved in the details of this project. You’re all professionals, and you are paid very well, figure it out and deliver the good. Let me know when you’re done and we’ll deliver it to the customer together.
1. The ultimate irony that I’ve never understood. Why do leaders disengage from really important projects that are struggling when their teams need them the most? Not micromanaging, nor remaining aloof, but truly helping the team negotiate and deliver an acceptable set of features.

These are simply 10 common diversions I’ve experienced with leaders trying to avoid the truth in one way or the other. Have you had similar experiences? Or care to share other examples of ways to deflect or avoid leading under adverse conditions? I’d love to hear more examples.

My Hope

My hope is that by making some of these reactions transparent, it will influence the “good leaders” out there to improve their reactions. So they start thinking about this pattern and trying to avoid it whenever possible. And start engaging their teams more and partnering with them on challenges, even when the going is tough or the answers aren’t what they wanted to hear.

That instead of avoidance, they’ll truly find the courage to effectively lead their agile projects and teams.

One final avoidance pattern, on the part of leadership, is often an inability to admit you’re in trouble, or over your head, and that you need help. Why is it so difficult to ask for help?

Perhaps it’s a bit of denial or inability to handle the truth? I also think there’s a bit of ego and hubris involved. Surely they’re in a position that requires them to “have all of the answers”. Well another part of solid servant leadership is showing humility, admitting when you’re wrong, showing some vulnerability, and…gulp…asking for help.

Please don’t shy away from these reactions as well. I truly think it’s a sign of strength in your leadership and not a weakness. And it will set a great example for your teams as well.

Wrapping Up

I hope this article hasn’t been too over the top or unkind to leadership. I’ve been in these same situations incredibly often over the years and I empathize with why leaders can find themselves in this denial and avoidance trap. Often they’re part of a dysfunctional organization or they’re a “lone voice” that nobody wants to hear. Or they’re personal lives and situation don’t support the notion (and ramifications) of “saying no”.

I get that.

But putting things off till later has never worked as a strategy for me. Things have always gotten worse. The best strategy that I’ve found for successful projects is engaging reality and your teams; then moving forward.

As always, thanks for listening,
Bob.

By the way, if you haven’t seen A Few Good Men or if you’ve forgotten about the scene, click here for a snippet.

Don’t forget to leave your comments below.