Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Agile

Agile is bad!


Not always. We have a tendency to solve problems we face with a single silver bullet. In the recent past, I observed an organisation trumpet it’s move to agile in multiple communications. This organisation had undoubted issues with delivering to commitments it had signed up for, and agile was seen as the way to fix all its ills. Yet, when I talk to those working in the organisation, they see little change. And surprisingly, the outcomes are no different now than before.

Agile-Or-Not

So is agile to blame for this? Or was waterfall methods (if indeed it was what they used) really to blame for their past failures. The reality is agile is not something that simply works. A cultural shift is required within the organisation to derive benefits from using any agile methodology. Without that, (so called) agile is just as bad as any other way of running projects. So what are the things that defeat agile in organisations?

Multi-disciplinary teams: Agile project teams must include subject matter experts from areas that they are delivering too. If a software is being written for automating taxes for accountants, then you must have accountants and tax specialists in your project team, along with your developers, testers etc. Technical staff cannot be experts, and this is why you will need subject matter experts. If experts get tasked with duties on top of their day job rather than dedicated time on the project, agile is bad for this organisation.

Decision autonomy: You get over the first hurdle and have the skills in the team that you need. Time comes to make the first choice between implementation options and your subject matter expert needs to get it approved by their manager, who is not available for rest of the week. If your subject matter expert cannot make decisions on the project with authority, agile is bad for for this organisation.

Urgency: A key tenet of agile is the delivery of working product at the end of each iteration. Iterations are intentionally kept short so prioritisation always focuses on highest value items, builds value incrementally, and avoids the bells and whistle distractions. If the organisation cannot get you decisions in a timely fashion, then you can be guaranteed to either twiddle your thumbs for parts of iterations, or pull too many moving parts into it. Either way, agile is bad for this organisation.

Change control: It is all well and good for the project team to work in an agile environment. What happens to the working product delivered by the team? Is the organisation geered towards receiving these products at such intervals? Can they cope technically? Is there enough staff to make it happen? Can the required training be produced in time? If the answer to these questions is no, then agile is bad for this organisation.

Procurement and audit: Agile planning is done in stages. Closer you are to working on an item, more detailed planning you undertake. In the course of the project, it may become clearer that delivering more in one area is of higher value than delivering on another that had initially been identified as a requirement. If the subject matter experts make this call and the organisation’s procurement or audit team later lambasts them for non compliance, agile is bad for this organisation.

The intent here is not to highlight deficiencies of agile methods. In fact to the contrary. Agile done well can be immensely valuable for organisations and an innovative and satisfying environment to work in. The key is to recognise agile requires a cultural shift in the way an organisation operates to make it truly worthwhile. You do not make agile project teams, you make agile organisations.

Sh*t ‘Agilists’ Say


My two cents worth

As an Agile coach I’ve had the pleasure of working with some of the best minds in the IT industry over the years. Unfortunately most of these individuals remain unsung heroes throughout their careers. But fame or recognition isn’t what drives these individuals, instead, it is the satisfaction of producing unique solutions to complex business problems day after day that keeps them motivated.

Being human beings however, even the best of us get frustrated, angry, agitated at times. In fact in all of my 8+ year career, I have never seen a team be able to avoid the storming phase from the  ‘Form-Strom-Norm-Perform’ cycle. Some have bridged the chasm quicker than others but all teams that I’ve worked with have had to go through this cycle.

My job as coach is to be there for my teammates through their team building journey; help them re-configure their mindset, encourage debate, encourage criticism while keeping emotions and ego out of conversations, enable…

View original post 1,355 more words

Where is the line between agility and chaos?


We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.

Aglie is NOT Agile IS
A methodology Agile is a set of principles.

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.

License to dive straight into code All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
License to develop without scope User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
License to change your mind daily User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
License to leave half finished work floating around Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
License to continually chop and change the team Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
License to pull resources mid assignment Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
Something that only works on its own Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.

To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.

When projects go too well


As a Project Manager, I strive to ensure my projects go really well. Experience tells me that all projects will go through some difficult periods during its execution. Projects are inherently risky and not all risks, influences and impacts can be predicted in advance. That and years of experience delivering projects has made me weary about a project going too well.

Ignorance is bliss. However, when exposed the results are seldom pretty. There are many reasons why a project may appear to be going better than what is the reality. The project team may have a different world view than that of the customer. This is a very common scenario, especially in the old days of long waterfall software development projects. The advent of the Agile methodologies has come about through a desire to remove this expectation barrier through short iterations where the customer has the opportunity for feedback. That alone, however does not guarantee success.

Many times, it is much easier at the start of the project because the pressure of deadlines is not so immediate. A day’s delay here and there does not seem to pose a great danger. There seems plenty of opportunity to make up for any lost time. However, as the project progresses, this becomes less and less possible. Unless the project is planned with enormous slack, in my experience it is impossible. The student syndrome is well and truly entrenched in project teams. If someone is given more time than is needed for a particular task, they relax too much early on and only put the foot down when they think they are nearing the critical path.

In the context of a supplier delivering products of services to a customer, the early days of projects are much easier. All parties begin with the intention of getting to the end goal in a one team approach. However, the business pressures are different on the supplier and customer. Therefore, even with the best wishes, a one team approach is very difficult to sustain over a long period. Equally, when the discussion is about benefits and approaches, it is a much easier conversation to have. As soon as the conversations move towards billing for costs from the supplier side, or project assurance or performance measurement from the customer side, discussions are inevitably more difficult.

Work cultures and how individuals behave during uncertainty also play a major role in project success. Some people have the tendency to not ask for help and hope they will be able to persevere through any difficulty they are having. They consider asking for help as a sign of failure. This can lead to drastic consequences, despite well meaning people. Bringing to attention any risks or issues to late in the piece will guarantee it cannot be successfully navigated through. There is no substitute to knowing your people.

The biggest mistake I see made when projects go well early is project teams sometimes get too comfortable and stop doing the basics correctly – keeping tabs on scope, documenting decisions, communicating effectively, enforcing change control etc. People are by nature reluctant to rock a boat they consider is sailing well. If you always hear everything is going well do not be content. Do some project management by simply walking around and getting the pulse of the team. Having a good handle on whether status reports reflect reality is a must. If there are issues, it is much better to know them early.

Do not relax when projects start well. You are under less pressure and should take the opportunity to compile good project management artifacts. If things turn sour, these are what will help navigate a course.

Image Credit: The New Zealand Railways Magazine

Is Agile for me?


If you talk to any project team, you will find varying range of opinions regarding the best methodology for development – all very passionately putting their points of view across. Barring the occasional accident, most of these teams have given considerable thought to what is most applicable to them and have followed that course. When each of them argue in favor of a different methodology, it is well founded in facts. However, the one thing that is missed in all these discussions is that the challenges facing all the different teams are not the same. Let us consider various scenarios.

Follow this scenario … an organization realizes the need for a new system. They go through an internal requirements gathering process and invite tenders for the system, to be implemented by a certain date. You are a professional services organization. You are required to estimate the effort required to design and implement the system. In your response, you have to provide a price, as that would undoubtably be one of the selection criteria. You happen to win the tender. What is your status? You are now locked into a fixed deliverable to the client, to be completed by a date within a cost you have specified. Is there any room for agility? When you think about the triangle of constraints, effectively you can move none.

You can legitimately ask why not estimate to do the work following Agile principles, that would solve this dilemma. Let us then review how business is done in the real world. For all of us IT professionals that like to think we’re God’s gift to mankind :o), the reality is that we’re a support cast in most organizations, that only utilize IT as a means to achieving their business goals. In business, everything is driven by supply and demand. Think of it this way … if you bought something from a store, you may be able to take it back and get something else that is in a slightly different color, or size. However, if you ordered something custom to be made, and then changed your mind on the size, would you expect that to be accommodated? This is the difference between a product sale and custom work. Software development is no different.

When you are developing a product, or are in a development or support team within the organization, you have a steady commitment to resources. You have the ability to select your sprint schedule. Your costs are also therefore fixed. You have some leeway on scope. In such scenarios the organization has already accepted the cost of this continued effort and therefore scrutiny on the resources (and by extension cost) is not the same. The scrutiny is likely to be more along the lines of value for money … is the overhead we have agreed to getting us the improvements (or new functionalities if it is a product development) we’re after.

Custom development is an entirely different beast. Here uncertainty reigns. Most likely reason the organization is getting you to do the project is they do not have the resources or capability to do it themselves. At the same time many of the users will also not have the understanding of what is possible to achieve. In such scenarios you will end up spending significant effort in communicating possibilities and success criteria for your work to be accepted. Encouraging change of requirements, even at late stages like Agile methodologies will ensure you never come in on budget or are forever locked into a change control battle.

The second key when considering using Agile methodologies is the likely size of the project team. In essence the Agile teams are self organizing teams that work based on a given set of requirements and set their own schedule. The emphasis is on responding to change over following a plan. This works really well and reduces overheads. However, this is only true for a small team. When the team size goes to beyond six or seven, this becomes more and more difficult. Adding each new team member adds many new lines of communication necessary to keep this self-organization working efficiently. Bigger the team lesser the chance of success using Agile methodologies.

If you have been landed with an Agile project because no-one knows the requirements, think again. That is a guarantee for chaos. Agile is not a substitute for requirements gathering. In fact, Agile requires a continued emphasis on requirements through product backlogs and user stories. There is a constant requirement to refine user stories, even for items that do not make it to the current sprint. Many a time customers will not object to time spent writing code and testing it. They will object to this continuous refinement and management efforts. Before you jump in, consider if your client is inclined this way.

Does this mean that you cannot use Agile principles at all in some of these scenarios? No, that is not necessarily the case. You can use Agile principles in your teams, but will most likely struggle to run the entire project using Agile practices. You will need something overarching to ensure adequate control and communication. Agile is best suited for product development and in-house support teams.

%d bloggers like this: