How Do You Know If You Can Use Agile On a Project?

shutterstock_133198406

Q: What elements in a project and its context should should be in place to assess if the project is “agilable”?
A: Determining whether a project is “ready for agile” is more a function of the organization than the project.

If the organization has successfully adopted agile practices, then any project is a candidate

In this case its a matter of taking the “next step” in terms of size and complexity.  It may mean taking on a longer, more important project, or it may mean introducing additional dimensions of complexity such as distributed teams or multiple teams.

If the organization is just starting out and is looking for a suitable pilot project, then small low risk projects would be better

This is because the emphasis will be on learning what works and what doesn’t work in the context of the organization.  The point to keep in mind is that when a company is transitioning to Agile, its not just learning the process, its learning how to deliver.  Part of that is understanding where the sharp edges are in the organization and where change needs to happen.

Lastly, to help with a decision matrix, seek the expertise of a good coach.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Colocated vs Distributed Teams

shutterstock_26157607

When we first start to learn about Scrum, we learn that face to face communication is the best way for humans to communicate (as opposed to paper requirements being thrown over a wall).

However, more and more clients are asking for some form of ‘Scaled out Agile’ or ‘Distributed Agile’ approach. What does this mean for ‘Pure’ Scrum as we know it?

I am not sure

What I am sure of is that increasingly we need to look beyond the walls of our own insular community for thought leadership on the areas that we increasingly find ourselves moving into: Human Performance, Organizational Change Management and Transformation, Lean Operations and Strategy.

I was talking to a client who wanted to embark upon the path to Agility, but has a massively distributed team (all in North America) and no travel budget.

My gut told me to say “Sorry, no travel budget, no Agile… its’ a lot easier to teach and coach people in one place”. Yes, it is. It would have also been easy for me to walk away from a potential engagement, but just like every engagement, it was an opportunity to learn. In other words, how could I challenge the conventional thought and find some nuggets of wisdom to share from this?

We will see. I am working with a virtual team, and I myself am virtual, travelling to the client site once every 2 weeks or so.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Importance of Agile Leadership

Bullseye!
Image by Gare and Kitty via Flickr

In my whitepaper entitled “Agile Estimating,” I talk about the importance of the business owning the prioritization of the backlog. I sum it up by saying, “If there is no prioritized backlog, there is no Agile project.”  I think this is worth repeating and worth a closer look.

When you look at the historic reasons *why* software projects fail, one of the primary classes of software project failure modes is the lack of appropriate involvement by business leadership.  This can be manifested by a lack of a backlog prioritized by business value, a lack of baselining of what constitutes high business value, or simple apathy on the part of the business.

While Agile is often sold as a ‘new IT method,’ I often say that the problem with Agile is that it doesn’t stay cleanly in IT, even though some organizations want to keep it there in a bubble, not affecting the rest of the organization.

In non-technology based Fortune 500 IT departments, I see this a lot.  An example is the industrial equipment manufacturer that has made lots of progress on the manufacturing and design side as far as rapid design and lean (demand-pull) manufacturing techniques but still uses the same predictive planning up front IT processes.

IT can and *should* be a competitive advantage for any organization and it should act as a value multiplier for the core business.  With that said, the core business needs to heavily involve itself in any IT project that will have a non-insignificant impact on operations.  ERP, CRM, PLM, and large custom-developed software all fall into this category.

One of the common problems with a lack of business ownership and commitment to a project is as follows:  An IT organization (whether it be internal or a consulting firm) is asked to implement an ERP system in order to streamline operations across the business.  There is much efficiency to be gained by having an enterprise system, but if there are no enterprise process owners of the enterprise processes that the system is implemented to support, you get a mishmash of incongruent processes and a myriad of bolted-on customizations to support the whims of various departments.  This demolishes the value proposition of the ERP system because the cost of maintain, supporting and upgrading the system becomes MORE expensive over time.

Senior leadership needs to make a visible and ongoing commitment to these types of projects.  They should be underpinned by a solid, well understood, and effectively socialized business case.  The governance structure should allow for quick decision making if there is bickering between divisions.  Last, but not least, there should be a robust organizational change management and communication strategy underlying the complete project.

There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

Watch the Baton, Not the Runner

The other day I was presenting a set of metrics for our sprint teams to a group of IT managers.  They asked about the burndown and what it meant in terms of scope creep.

I explained that everything the business lists as a requirement after they see working software we take down as a gap or a bug, then it is prioritized along with the other laundry list of scope items.  We have limited time and budget, so the items that are of highest business value will be delivered first, and so on.  If the business sees a gap as higher priority than one of the previously identified areas of scope, that’s fine, we take it into account and move it up the list.  That way, we are always aligned with what the business deems highest priority.

They asked about the backlog and how we could tell if a project was ‘late.’  The concept of a project being late is predicated on a predictive schedule, which we weren’t following. Since we are following an adaptive schedule, it’s not so much about late as much as it is about what won’t be delivered based on time and resources.  They were ok with that.

As I began talking about feature velocity and how we measure it, one of the managers asked, “Yea, but how can we tell how efficient our guys are?”   The answer to that question is that I consider ‘efficiency’ a false metric.  That is to say, it gives everyone the warm fuzzies to talk about ‘our developers are 99% efficient,’ but when it comes down to it, feature velocity is a much more effective measure of how well your team is doing than how much of their time is utilized.

It reminded me of the “time and motion” studies they used to do to measure worker efficiency

For an assembly line manufacturing environment, this might be a good indicator of factory output if you have a standard number of widgets that a worker creates in an hour.  But for software development, it might not be so good of a measure because software development ebbs and flows and has breakthroughs and backtracks.

Ultimately if we see the delta between the team’s estimates and actual decreasing and we have an increasing feature velocity sprint over sprint, that should be all the measure we need to show the process is working as designed and that the team is getting better at delivery.  In other words, if it’s a relay race with a team of 6, it’s not the team that is running 100% of the time that wins, it’s the team that masters the dynamics of teamwork and handoffs that is most effective.  The team who gets the baton across the line first wins.

The baton is value!

Reblog this post [with Zemanta]
There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More

What is Organizational Change Management?

shutterstock_189612908

Organizational Change Management Definition

Wikipedia defines Organizational Change Management as follows:  “Organizational Change Management aligns groups’ expectations, communicates, integrates teams and manages people training. It makes use of metrics, such as leader’s commitment, communication effectiveness, and the perceived need for change to design accurate strategies, in order to avoid change failures or solve troubled change projects.”

This is important for Agile Project Management because when we look at large enterprise projects this is most often the cause of failure.  We have a stellar project manager, we have a superstar team of developers, a highly astute group of business analysts, and a core team of wizard architects, yet the project was still seen as a failure.  Why?

Why Organizational Change Management is Important

Because the most talented project delivery team and the most sophisticated whizz bang technology doesn’t change the basics of human nature, and one of the basics of human nature is that people are resistant to change.  OCM is a discipline that studies change in an organization (easy, right.)

Let me state it again:  People hate change. When an engineer in 2010 looks at the DOS program that Mary has been using for the last 15 years to enter orders, then sees her print out the manifest, take it to Bob, who pulls the order from the shelf, writes the date, time and release on a piece of paper, then takes it over to Ned who gets it ready for shipping, he sees a Rube Goldberg machine that if properly digitized, optimized, and streamlined could unlock all kinds of value for an organization!  Excelsior!

Not so fast Sparky

Mary knows how to do her job.  Bob knows how to do his job, and Ned knows how to do his job.  They have ingrained patterns of behavior that give them a certain level of comfort with the current system, warts and all.  If you come in with a customized automatic digital sign-off and order routing system, the whole order to cash ecosystem could very well come to a screeching halt.

As Agile project managers and technologists, we cannot continue to look at software development and packaged software implementations in a bubble.  We need to recognize that the cause of ‘perceived’ failure for many a project is the lack of understanding and respect for how and why people are prompted to change.

Where I have seen people fail

I have looked at many technology project plans and have seen no provisions for guiding the organization through the change curve.  Zero understanding or respect paid to training the users (what do you mean, I’m a UI GURU…. IT’S INTUITIVE!!!).  Try telling that to Mary when she says, “It just doesn’t work!”  What she really means is “It just doesn’t work FOR ME.  I didn’t buy into the idea,  I wasn’t prepared, I wasn’t trained and dammit I don’t like it!”

How to approach organizational change management

The next time you are envisioning a project, don’t just think about the developers, dbas, architects, testers, and business analysts.  Think about a communication plan (early and often).  Think about how you can get executive leadership to take a visible role in enabling change in the organization.  Think about how you can expose the organization to the project progress, goals, and value.  In short, think about your customer.

Reblog this post [with Zemanta]
There was an issue loading your timed LeadBox™. Please check plugin settings.

Read More