Project Management

A Hammerhead Shark versus James Bond in Speedos

A  Hammerhead Shark versus James Bond in SpeedosI’ve often found that most of the questioning about the worth of agile tends to come from the Project Management community. That’s not a criticism on PM’s but an acknowledgement that for them it’s probably more difficult to see how this agile concept can work.

Traditionally PM’s have tended to need their eyes pointing in different directions – one on the day to day development activities of the team, the detailed planning and daily progress, and one on the bigger picture, the long term roadmap and strategic planning side of a project. And, unless you’re a Hammerhead Shark – this is always going to be a tricky feat.

The trouble with agile, or more accurately, the trouble with some people’s interpretation of agile, is that it can be seen as an excuse to just focus on the tactical side of planning which leaves PM’s wondering what happens to all the stuff their other eye is usually pointing at.

So does being agile really mean ignoring the high level strategic side of managing and planning a project? Will the scent of burning Prince2 manuals soon pervade?

Fortunately this is not what agile means at all – in fact Scrum, which we all know and love, is pretty keen to remind us that we should still do release planning, risk management, and all those important things, it just doesn’t presume to tell us how to do them (in much the same way as it doesn’t tell us how to breathe, eat, sleep or do any other number of bodily functions we should still be doing whilst we’re Scrumming). What we are left to figure out for ourselves, as fully capable agile dudes, is how to ensure that we can stay agile for the long haul, which means having a sustainable and scalable approach to agility.

So how does that work? Is it really possible to add the governance, compliance, risk management and high level planning elements of managing a project to an agile approach without losing the agility? (Let’s hope so, for agile’s sake, because it is clearly and undeniably necessary).

Well, yes, of course, it is possible – otherwise agile just wouldn’t work. But it has to be done in a certain way. Let’s face it – you wouldn’t send James Bond out in full suit of armour, a wetsuit, padded ski suit and a parachute every time he went on a mission. Not only would it be a tad cumbersome, it would also be unnecessary (given that sometimes he gets away with just a small pair of Speedos). What you would do is give him exactly the right amount of kit required for a given situation. The same applies to agile. What’s needed is exactly the right amount of governance, planning and compliance for a given project – no more, no less.

So hang on – what have we got so far? James Bond in Speedos and a hammerhead shark. Which one is the PM? Well in a way it’s both, and neither. Confused? Good. Me too.

And I guess that is the point. A PM’s job is not easy and while they would love to be 007 in speedos (figuratively) – agile, unencumbered, able to work quickly and focus on getting the job done, they still need that hammerhead with one eye on all the ‘other stuff’.

I don’t think we can ever get rid of all that ‘other stuff’. It’s necessary and important. But we can minimise it so that only the right amount of ‘other stuff’ is put in place and we do what NEEDS TO BE DONE, building up from a minimal set (should I mention speedos again?) rather than starting out with everything, including the wetsuit and the parachute. This then, in essence, is the key to disciplined agile.

The PM still needs and will always need to be able to look at both the strategic and tactical side of a project, but with this approach maybe they need be less of a hammerhead. With agile self-organising teams the tactical planning side of a project is very much a team effort and, along with release and sprint burn-downs, daily stand-ups and sprint retrospectives, the tactical management is much less of an overhead.

So maybe, now, a normal shaped head will do, with just two eyes and some kind of innovative mechanism that will turn that head, allowing the PM to focus on the strategic but throw a glance towards the tactical when necessary.

Or maybe I’m just sticking my neck out.

Learn more about lightweight essential governance for agile projects.

Read the article: Agile and SEMAT - Perfect Partners.

What does it mean for the enterprise to be agile?

What does it mean for the enterprise to be agile?Closely allied to establishing the business objectives in adopting agile practices, an understanding of what it means for an enterprise to be agile should be clear to everyone in the enterprise. This post summarizes what it means for an enterprise to be agile from the perspective of the senior executives and stakeholders.

“Agile” is a set of behaviors that help a business achieve its objectives. The most prevalent agile practice, Scrum, defines a set of project management-based behaviors that help practitioners (especially software practitioners) achieve those objectives. However, little is said in Scrum about how to be agile outside of the immediate environment of the Scrum teams. Team agility does not automatically engender enterprise agility.

Deciding where a so-called value chain starts and ends is going to vary according to the individual enterprise considerably, according to factors such as size, business area, degree of specialization, vendors and suppliers as part of the larger value chain (or even ‘ecosystem’). However, this is a bit like a “5 WHYS” analysis, you have to recognize where it makes sense to stop the analysis at. Mostly, a company’s corporate boundary makes a natural place to stop (though ideally the whole external supply chain would be synchronized and agile). However, this may be too great a challenge for many organisations to begin with, so smaller organizational units and business units within the enterprise may have to suffice for the initial vision and implementation.

As a reference point, for a hardware-based product company, the groups that might be considered for inclusion in the scope for enterprise agility could look like: Sales, Marketing, HR, Executive Management, Software Engineering, Hardware Engineering, Product Definition, Product Releasing, Product Testing, Technical Documentation, Project Management, Programme Management, Quality Assurance. Where any of these groups are excluded, there will probably be a detrimental reduction in overall agility.

Here are some of the major characteristics that an agile enterprise will typically exhibit, at the ‘manager’ and ‘senior executive’ levels (some apply more to some groups than others):

  • Commitment through close involvement and engagement with agile teams
  • Removal of organisational impediments and issues
  • Flexibly determining release content and being responsive to change: based on sustainable organisational capacity and economic value (including cost of delay); taking into account (test) results and feedback
  • Be Servant Leaders: inspire, motivate, lead by example: including: allowing teams to self-organise - “Self-organisation does not mean that workers instead of managers engineer an organisation design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviours that emerge from the interaction of independent agents instead of specifying in advance what effective behaviour is.” – Philip Anderson, The Biology of Business
  • Demonstrating trust, especially in avoiding delving into (and controlling) the detail: but note also that trust is engendered by successful delivery
  • Focusing on throughput of (valuable) work rather than on 100% Resource Utilization
  • Recognizing the differences between repeatable and highly variable knowledge work (avoid purely “widget engineering”)
  • Evolving legacy practices into new (e.g. by evaluating and challenging old Ways of Working): powerful corporate forces can be afoot, so this is not easy.

Leffingwell’s Scaled Agile Framework provides a suitable structure for scaling Scrum to enterprise levels and fills in on many of the executive roles and functions required for success in agile at the enterprise level.

Some useful links:

Iterative Sprint Planning

I’m encountering a recurring theme in my agile coaching. Some organisations have a sharp divide between their business and IT functions. This always spins off a twin-track coaching path for me: on the one path let’s try and address the fundamental root cause of the dysfunction/divide and on the other path what can we do to ameliorate and get around the problem in the short term?

So far my experience is that most of the symptoms of this issue are revealed via the Product Owner role. Sometimes business folks just don’t understand the basics of either software engineering or software economics. It’s just a simple inevitability of the organisation and experiences/skills their career paths have taken them on. So they can be experts of the business domain, but appreciate none of the pain and realities of software development. That is not a trivial problem to solve and will likely take a lot of effort and time. So in the meantime, what should we do to minimise the impact? Well, for sure, this is going to depend on all sorts of factors surrounding what exactly the problems are being created by having Product Owners with no software experience.

I’ll describe what I have found works quite well at one particular client in regard of one slice of this overall challenge: Sprint Planning.

The difficulty faced by the agile teams was that the allotted time Sprint Planning was always reached before any kind of commitment to the content of the Sprint was close. On closer examination, there were (as so often is the case) a number of contributing causes for this and all need attention. As well as the common issue of developers being uncomfortable with the relative sizing of backlog items without knowing almost every line of code impacted (they may have got bitten in the past), the thing that seemed most acute was the compounding problem of unclear requirement. With the lack of an empowered and embedded full-time Product Owner, it was perhaps inevitable that even well-formed User Stories were insufficient in getting a shared understanding of the requirement to the agile team(s). In this circumstance, we have used a Business Analyst as a proxy Product Owner with regard to backlog generation.

Scrum and similar methods describe the Sprint Planning event in some detail. They suggest a planning meeting of around four hours per two-week Sprint. There is also a recommended ≤10% allowance in the Scrum Guide for backlog grooming and refactoring by the whole team. By converting that ≤10% grooming into more structured events, we are finding it much easier to contain the planning to the suggested time boxes. The structuring consists of three iterative parts to Sprint Planning:

  • GET-AHEAD sessions. The proxy Product Owner meets regularly with business (and other stakeholders) to discuss upcoming requirements a Sprint or two ahead of when the requirement needs to be delivered as a backlog item/ User Story. By starting these meetings ahead of the Sprint execution, it gives the diverse stakeholder community the opportunity to address issues and questions raised concerning the requirement. Typically, this was left until the Sprint Planning meeting previously, giving no time for issues to be analysed and answers to be gathered. This not only gummed up the Sprint Planning, it also blocked the subsequent Sprint execution. The agile team need not be involved in the GET-AHEAD sessions (it isn’t an effective use of their time) – this helps reduce the overall amount of time that the team spends in planning sessions.
  • CONFIRM sessions. Once the proxy Product Owner has established the requirement to a comfortable degree, the backlog refactoring would continue by discussing the requirements with the team. By this stage the requirement is largely understood by the proxy Product Owner so whilst business stakeholder attendance could be useful, it wouldn’t be mandatory. Discussions in the CONFIRM session are generally more technical and where the Product Owner is not of a software background, this is of limited interest to them and not a great use of their time. Whilst the proxy Product Owner would be able to answer most questions that the team would have, sometimes more questions may be raised and these are taken back to the next GET AHEAD session (hence the process is iterative). Typically relative sizing of the stories (through planning poker) starts in CONFIRM sessions but not task decomposition.
  • COMMIT sessions i.e. the Iteration Planning Meeting itself. Once the major issues have all been resolved in good time, the team can confirm the story content and sizes, do task decomposition and estimation, then commit to the delivering the work in the impending Sprint.

By following this process in an iterative way (just enough planning in just the right amount of detail), we have been able to get much more meaningful Sprint Plans produced just in time. There is still some way to go to get this working in an optimum way, but we have reduced one major impediment and can now move onto tackle others…

Funding New Projects

In a prior blog entry I noted the traditional approach to funding new development efforts:

  1. the business gets an idea and writes a few sentences of description,
  2. IT tries to figure out what the business really meant and comes up with an estimate based on their best guess, and
  3. this amount gets locked in as a "committed" estimate to which IT is held accountable. 

The only thing that should be committed is the people who think this is a sane approach to funding projects.

A better model works like this:

  • The business identifies a set of desired business outcomes that they would like to achieve, along with the net present value of achieving those desired outcomes.
  • Based on this value, the business decides how much it is willing to spend to achieve those desired outcomes.  Usually this is based on the required rate of return of investments in the business.  This amount establishes an upper limit on the project that could deliver those outcomes.
  • The IT planning process then focuses on determining whether the desired outcomes can be achieved within the constraints established by the business planning process.  If they cannot, further funding for the project is stopped and more worthy projects are funded.  Several alternative approaches may be tried and rejected, and deciding project feasibility may require some prototyping and evaluation to determine viability.

This is how research and development funding works and, let's face it, software development has a lot in common with R&D: both deal with a lot of unknowns at the start of a project, so much so that it is usually not possible to precisely define the exact work that will be needed to achieve a particular end.  Both R&D and software are essentially exploratory: at the beginning of the effort the exact result is not known with a high degree of assurance so we have to evolve toward a solution.  The current funding model's assumptions that the solution is easily definable and therefore should be easy to estimate just doesn't work for most new software development efforts.

Light Weight Software Development Process #2

The Software Development Process Challenge

*The first post in this series can be read here

Before I describe the deck of cards, I’d like to set the stage for using the cards. We can view software development from three time-scales (see Figure 1). Successful software development process is in essence, being able to coordinate the three time-scales effectively.

  • The broadest time scale covers from the beginning to the end of a software development cycle which is marked by several key business decision making milestones. This is of great interest to stakeholders and decision makers on whether development can proceed or whether the software is suitable for release.
  • The next time scale breaks the lifecycle into time-periods – months, or weeks, or what is known as an iteration. It is a fixed time-box where a number of target objectives are to be met by a development team. If there are multiple teams, then each team would be assigned their specific set of objectives. This is where team leaders operate.
  • The lowest time scale is what a team member does. The work done here can be in terms of hours or days depending on the complexity of the work.

Light Weight Software Development Process #2

Figure 1:The Three Perspectives to Software Development.

A major problem I see in many development organizations is the serious disconnect between the three levels. The objectives set at the higher level do not easily translate to work at lower levels. Lower levels are unable to see their contribution to higher level objectives. There is a  miscommunication between the levels, and poor coordination within the same level, which leads to blockages which should not even happen. We need to solve this.

Attitudes regarding risk and change

Attitudes regarding risk and changeMost project management approaches address risk in a fairly superficial way: risk mitigation is viewed as an important activity, but one that is largely a distraction from the main effort of the project. Risks are identified at the start of the project, they are usually assiged to someone to address the risks, but these risk-mitigation activities are largely viewed as things that take away from the project work. In practice the risks are only identified once and then they are largely forgotten in the large amount of work to be done.

On a traditional project, change is viewed as a bad thing, and great efforts are undertaken to prevent it. Change disrupts the original plan, and it is the plan (and not value delivery) that is sacrosanct on a Traditional project.

Similarly, change must be embraced. Change results from new information, from feedback that something in the original plan will not result in the desired end result. Change is something that will occur as people get new information, but change is a good thing: it means convergence on the right solution. Read More

More accurate requirements: when process is lost

More accurate requirements: when process is lostOver the last few days a number of people have asked me the same question: “How can we get more accurate requirements?” While I agree it is not nice to answer a question with a question, in this case you might bend etiquette a bit because in reality this question can be hard to answer. For example, why is it necessary and which problem does it solve? Or, what exactly do you mean with accurate?  And do you have accurate requirements and you want more of those? And in that case, more than what? Or do you have inaccurate requirements which you want to become more accurate? And if so, how much more?

You might say: “Hey, that’s just playing with words”. Well, that’s right and so is writing and communicating requirements. In order to get accurate requirements you need a number of things. However, an often overlooked element to writing accurate requirements is understanding the structure of language and how language is perceived. Read More

An Iteration Has a Distinct Set of Activities

An Iteration Has a Distinct Set of ActivitiesEach iteration is unique. It involves undertaking a unique set of activities to produce a unique version of the product that objectively demonstrates that the iteration objectives have been met.

Because of this uniqueness, each iteration requires its own iteration plan. The iteration plan contains the details of all the activities that the team is required to do to meet the iteration objectives. The amount and style of activity-level planning required for a project is dependent on many factors including the project risk, team size, experience levels, and the manager’s own preferred management style.

For some projects, an informal plan describing the goals to be achieved and listing the tasks to be undertaken is sufficient; you can leave the scheduling and allocation of the activities to the development team. Other projects require more comprehensive plans that describe the activities and their allocation in greater detail to work out the dependencies between the tasks to be performed by the various team members. Read More

"Earning" earned value by Ivar Jacobson

Traditional project management approaches focus on planning in detail, assigning the resulting tasks to people and then tracking "progress" as measured by completed tasks. The problem with measuring progress this way is that completing a task, while important, is hard to correlate with progress against the overall goal - just because you've completed 20% of the tasks does not mean that you're 20% done - and for tasks that take a long time to complete the self-reported estimates of "percent complete" is often merely "wishful thinking".

My preference is to measure progress in a concrete and measurable way - in the form of tested scenarios, following an iterative project management approach.  In other words, planning works iteration by iteration, with each iteration developing and testing one or more scenarios.  At the end of each iteration, you have a set of developed and tested scenarios, making progress easier to measure: knowing that you've developed and tested 20 out of 100 scenarios is a lot more meaningful than knowing that you've completed 20% of the tasks - especially if those tasks are focused on creating documentation rather than running and tested code.  Scenarios correlate nicely with business value - each scenario should be useful to at least some subset of the stakeholders.  In my view, only when you've successfully tested a scenario can you claim to have "earned value".

Measuring Project Success and Managing Expectations by Ivar Jacobson

There are a number of studies that cite poor performance of software projects - The Standish Group being the authors of one of the more often cited, their Chaos Report (and old version from 1995 is posted here, and although the data is old the conclusions are not dramatically changed).  The gist of these studies is that the majority of projects (as high as 70%) fail when measured against original schedule, budget, and expected features. I would be the last to argue the general conclusion: that it is very hard to manage a project to success. 

Most projects lack clear direction and purpose, and many are rife with disagreements about what success looks like.  There is, however, something in the assumptions behind these studies that rings hollow: that the initial schedule, budget and expectations for projects is a reliable milepost against which to measure. Most projects are vaguely conceived at best - they often lack a clear understanding of why they should exist and what problems they need to solve.  At their initiation they are usually poorly scoped and vaguely purposed, and the funding associated with them is often assigned based on an  allocation of an arbitrarily assigned budget.  Their schedules, at least those produced at the start of the project, are largely speculative endeavors, a mixture of gut and guesswork, that bears little basis in reality.  Measuring project performance against the initial schedule, scope and budget is of little value except to illustrate the point that there is a large disconnect between the expectations of business sponsors and the ability of teams to deliver against those expectations.  There are, to be sure, rampant problems with performance, but there are also widespread woes of expectations that are just as important to address.

Where should we start?  The first place is probably with project funding and measurement. The real thing of importance to measure is whether the project produced (or exceeded) the business value  expected of it.  If a delay in the project caused a market window of opportunity to be missed, that is significant, but it is the decline in value delivered that needs to be measured, not a schedule variance that cannot be correlated with economic activity.  Forcing a focus on business value produced would also put the right attention on the role of the business in following-through on their assertions of the value that will accrue from having the solution.  Requesting projects based on business needs has an opportunity cost - choosing one project over another should affect the value delivered to shareholders - and accountability for assertions by the line of business is just as important as accountability for project delivery.

If we shift our attention to value delivered rather than meeting schedule and budget, we may free the development team to find better ways to deliver the value, which may or may not include the initial set of features envisioned by the business sponsor.  Initial feature lists are usually vaguely conceived and don't provide a very good target for delivery.  Work is usually required to ascertain the real needs from this initial list of "features", some of which contribute to satisfying real needs but many of which are simply good initial starting points for discussion about real needs.  It may very well take longer than expected to solve the real problems (it usually does, as we all tend to be more optimistic than we should about how long things will take).

The problem is that most teams are set up to fail from the start.  By measuring them against budgets and schedules based on arbitrary assumptions and often a poor understanding of the real business value that needs to be produced, we find them constantly struggling against a plan that cannot possibly succeed.   Measuring against initial schedule, budget and expected features is not merely meaningless, it's actually part of the problem.  We need to shift our focus to better articulating problems to be solved and needs to be satisfied, and measuring business value produced.  Once we start to do that, we can focus on the plans and milestones needed to ensure the delivery of business value.