Join us for “Intro to the Agile Mindset”

Last Updated on Monday, 1 April 2013 09:22 Written by Jesse Fewell Monday, 1 April 2013 08:53

Friends,

I’m really excited to announce that I (Jesse Fewell) will be appearing TOMORROW for the latest PMI Agile Community’s Tweetchat. The topic is “Intro to the Agile Mindset”. We will all be on Twitter TOMORROW, April 2nd at 12pm EDT (Eastern US). The hashtag will be #pmiagile and I’ll be tweeting as @jessefewell with some commentary by @leadingagile.

Some of the proposed questions include:

• Q1: What is an Agile Mindset? #pmiagile
• Q2: How do I adopt an Agile Mindset? #pmiagile
• Q3: What barriers are there to an Agile Mindset within organizations? #pmiagile
• Q4: How does an Agile Mindset impact teams? #pmiagile
• Q5: Is Agile the same as Scrum? #pmiagile

Hope to see you then

Agile networking communities in your area

Last Updated on Tuesday, 26 February 2013 09:49 Written by Jesse Fewell Tuesday, 26 February 2013 09:30

The best way to advance your agile journey is to get plugged in with others who are doing it. Here is a quick list of local and virtual communities, where you can find other practitioners like you. Note that some communities are registered in only one place, so click through all of them to be sure your find the right group, and get connected today.

The Agile Alliance lists the most extensive list of local agile communities:

http://www.agilealliance.org/resources/agile-user-groups/

Networking Groups with an emphasis on Scrum:

http://www.scrumalliance.org/user_groups

The Agile Leadership Network has a number of long-standing chapters across the world:

http://www.agileleadershipnetwork.org/local-chapters/

The PMI Agile Community of Practice boasts a virtual community of 13,000 project leaders using agile methods:

http://agile.vc.pmi.org/Public/Home.aspx

In organizational change, culture comes last

Last Updated on Tuesday, 2 April 2013 07:25 Written by Jesse Fewell Friday, 22 February 2013 12:00

courtesy @opensourceway

Here at LeadingAgile, we have a specific cycle for achieving organizational transformation. In short, to make real substantive change, you need to attack the following dimensions

1. Organizational Structure: 
2. Processes, Practices, Policies
3. Cultural Beliefs

…in exactly that order. That’s right, when you go to change an organization for the better, you need to do the culture part last.

“But wait, Jesse. Isn’t culture the most important ingredient of an organization? What about the phrase ‘Culture eats strategy for breafast’? Why not do the most important thing first?”

I’ve been coaching this to my clients for a while, but in the past few months it has become painfully evident to me that Rule Number Zero for “going agile” is to have stable team rosters. One of my clients has the habit of shuffling people from one project to another, with no notice. When I started talking to them about the mechanics of user stories or other such details, they simply couldn’t care less; they were overwhelmed and tired from getting yanked around. A different client actually KNEW they had to re-organize their teams to be more focused. But while senior management was busy socializing the new org chart for 4 months, the teams were thrashing, fully convinced that management didn’t have the fortitude to effect any kind of real change.

Some of my colleagues think that if you go straight to modifying the cultural mindset of the leadership team, you will get the momentum you need for lasting results. But the problem is you can’t get there from here. There is a known, methodlical process for changing people’s mental models. Specifically, consider that the same process applies for people struggling with personal dysfunction. Think about it. To achieve behavior modification,

1. First, get out of the environment that enables the dysfunction, and get into a support structure
2. Then, leverage that support structure to work through a 12-step program
3. ONLY THEN, can you introspect and self-actualize yourself as the new person

Granted, it is an iterative cycle:

• Change one small environmental thing =>
• to create the space to change one small process =>
• which slightly shifts my confidence based on a known track record =>
• which motivates me to make another environmental tweak…

But the point here, is that the iterative cycle of behavior modification is that you can NOT change a belief system, until you first have some positive behavioral evidence, which only happens after you create a safe and stable operational environment.

What about you? Have you seen the latest mission statement, management fad, or feel good effort yield zero results in your day to day work?

How to Calculate Budgets For Agile Teams

Last Updated on Monday, 26 November 2012 07:50 Written by Jesse Fewell Friday, 2 November 2012 12:27

A common concern I get from Agile newbies is “how do I calculate the cost of my agile project, if I don’t do all up front planning?” Actually, it turns out that when I leverage agile methods to simplify my project accounting,  budgeting becomes much easier. I’m going to show you two approaches that leverage two powerful attributes of agile projects.

Powerful Attributes of Agile Projects

Stable Team Roster. Project managers across the world agree that a key risk for any project is getting your people yanked off the team, or having new people thrown onto a team only at the last minute. This is the evil version of “Resource Leveling”, and it prevents any reliable forecast of a project burn rate. So, let’s see what happens when we request, nay demand, a stable team roster.

Time-boxed Iterations. Rather than try to calculate the budget of a team across 12 months, I want to simplify my problem. If we work in 1-month time-boxed iterations, I only need to calculate the budget of a given iteration. Let’s see how that works below.

Approaches for Calculating Agile Team Budget

Using a Blended Rate: When I worked at Marriott International HQ outside of Washington DC, project managers did not have visibility into the people’s compensation. Instead, we used a common “blended rate” of $125/hour. HR estimated the total loaded cost of the organization came down to that one number. Let’s assume I have a team roster of 12 people, but 4 of them are half-time, yielding a total of 10 Full-Time Equivalents (FTEs).

=> $125 X 8 chargeable hours per day = $1,000 fixed burn rate per person per day.

=> $1,000 X 10 FTEs on my team = $10,000 fixed burn rate per day.

=> $10,000 X 10 chargeable days in a 2-week iteration = $100,000 fixed iteration burn rate.

Using Specific Labor Categories: In other organizations, the Project Manager has to capitalize labor costs according to specific categories. For that we can’t over-simplify the problem with a blended rate.

=> Annual loaded cost of each team member / number of theoretical iterations in a year = fixed burn rate per iteration for that team member

=> Sum (every team member’s specific fixed burn rate per iteration) = fixed iteration burn rate

In the example below, I run these calculations to derive a $19,350 fixed burn rate per iteration.

Sample team costs

So What?

Having a fixed, reliable iteration burn-rate is killer. Once I have that budgetary metric, I finally have some compelling talking points around common conversations:

• “Mr. Client, our agile release planning session says the ‘social media’ initiative will take 5 iterations, totaling $250K. Is it projected upside worth the cost?”
• “Yes, Ms. Vice President, we can add that emergency feature. However, the team says that will take another 2 iterations costing $100K. Can you authorize the additional budget?”
• “Team, we have to be ruthless about bugs. Any bug that prevents us from going live will cost us $50K in an extra iteration, and I don’t want that coming out of my annual bonus.”

• “Sure, you can take the senior tester off my project. But that will cause my current iteration to fail at a cost of $50K. Plus the team feels it will add another 30% risk of missing the deadline for the remaining $200K worth of work. That puts the total financial impact at $50K + (30% x $200K) = $110K. Are you prepared to eat those costs as well?
• “I know we are falling behind, but If we extend the iteration until we feel we are done, I have no way of forecasting the financial impact. However, if we simply extend the project by one extra iteration, I can tell you it will cost exactly $50K.”

What about you? Have you found agile projects to be easier or harder to budget?

Effective Risk Management That Isn’t Boring

Last Updated on Friday, 16 November 2012 01:26 Written by Jesse Fewell Friday, 24 August 2012 04:00

Last week at Agile 2012, there were a couple Risk Management talks that blew my mind.  I was already comfortable with the notion that Agile methods offer a set of effective IMPLICIT risk management practices (e.g. iterative learning cycles, fully tested iteration increments). But this past week, I learned the community is beginning to mature a set of EXPLICIT risk management practices that can be embedded in your Agile methods.

Mike Griffiths shared his experiments with using collaboration games to improve Risk Management practices. He has a multi-part blog series that goes through the approach in detail, but the most important  can be summarized in 3 points. Meanwhile, LeadingAgile’s very own Dennis Stevens had a talk where he challenged people to move beyond 1-dimensional thinking. Here is my summary of the key points from both talks.

Make risk planning more engaging. In his talk, Mike asserted that we need to get beyond the idea that Risk Management has to be boring academic exercise. He does this by renaming the standard risk management processes to be more playful. “Risk Identification” becomes “Find Friends and Foes”. “Qualitative Risk Management” becomes “Post Your Ad”, where risks look more like a job board. This helps us get over the anxiety of being perfect or technically correct.

Make risk planning more holistic. Dennis suggested we involved multiple disciplines in risk analysis, rather than just the ivory tower project manager. Technical people, operations people, HR people, all need to be a part of the conversation. He also highlighted our tendency to go straight into the weeds (“IF the shipment of servers is late, THEN our testers will be late getting started”). Instead, Dennis proposed a multi-tiered taxonomy for thinking about risk at progressively higher levels. Specifically, a Risk Category (e.g Security) will cover many different Risk Drivers (e.g. Fraudulent Transactions), which will in turn unearth the Risk Events (“IF a customer deposits  More people thinking about risk at more levels.

Think of risk at multiple levels

Make risk planning more visual. Mike shows a few examples of hands-on collaboration games for performing the risk management processes. This moves the risk conversation into a more whole-brained activity, where both left and right hemisphere activities are engaged. Also, it keeps the risks front-and-center in our minds as we perform the project, rather than having them archived in a spreadsheet somewhere.

Team’s visual brainstorm of risks

What about you: What EXPLICIT risk management techniques do add into your Agile projects?