Aterny Blog

Latest From Our Blog

Look at this from an organisational perspective. The portfolio of projects currently underway in your organisation represents a significant investment. Assuming they are following an Agile approach, how do you know that they are being well managed? The project manager needs to demonstrate that the project is fully under control. The key is to ensure that the project manager is tracking and reporting the right things, and doing so in a manner which involves all the appropriate stakeholders. These elements of control are : Risk, Benefit, Quality, Resource, Time, Cost, and Features The project team should be able to demonstrate that risks have been identified, they have determined how much risk is tolerable, and are managing risks appropriately. Identifying the business benefit to be delivered is one of the key steps in the early Feasibility and Foundations stages, defined as the Must Have and Should Have requirements. These are easily monitored as each is delivered. The level of Quality, too, should be determined during Foundations, and monitored by testing adherence to those acceptance criteria regularly and repeatedly. The resources being used on a project are also easily measured on an ongoing basis, and are linked to the costs. Fix the resources (as we should on an agile team) and it implies the costs are fixed as well. DSDM Atern is specifically designed to guarantee on-time delivery. Consider this diagram: The left-hand side represents the traditional approach – fix the scope and then estimate the time taken to deliver it all. The right-hand side represents the Atern approach – determine a realistic estimate for delivery of the scope of the project, fix that date and then flex the detailed features according to business priority in order to meet that delivery date. Now, how do you ensure that the projects are going to deliver on time? And what are they going to deliver? Firstly, make sure that you have done enough up-front thinking during the Foundations phase. It is well worthwhile having a formal review with the project stakeholders at this point to ensure that the project team is properly prepared to start building a solution (see the post on Foundations for details). Atern, like other agile methods, emphasises iterative delivery. And – think about it – this provides a simple means of tracking progress. At the end of each timebox, demonstrate to your stakeholders what you have delivered, and that you are on track (or not) to deliver all the Must Have and Should Have requirements on the date scheduled. If not, corrective action can be taken sooner rather than later. These regular review points provide the perfect opportunity to ensure that the project is still on target to achieve its benefits and to review the processes and practices in use and whether they need to be changed to make the team more effective (the retrospective – don't underestimate the benefits of running these). The key is communication. Making these measures visible is vital to ensuring a healthy project environment. So: 1) Involve the whole team in planning workshops. Make sure the whole team commits to the plans each timebox 2) Hold demonstrations to a wider business audience whenever appropriate. 3) Report on progress within the team daily, and externally at the end of every timebox, based on requirements (user stories) delivered and accepted by the person who raised the requirement in the first place, according to identified acceptance criteria. 4) Involve the business and stakeholders at every opportunity. Make sure that what is being reported is factual. Making visible measures of all the control elements at the lowest level – the development timebox – means that stakeholders will have little need of any other subjective, biased status reports because they are involved and can see first-hand what is going on. Engagement and communication is the key to making this work. Continue reading
What is the common thread in the following list of oft-cited causes of project failure? * Unclear goals and objectives * Poorly explained requirements * Lack of user involvement * Scope creep Yep – poor communication. It is not the sole root cause of project failures of course, but good, open, honest communication can solve so many of a project's problems. Traditional project management methods emphasise communication by documentation – possibly the least effective form of communication known to man. Scott Ambler and Alistair Cockburn (say Coe-burn), have both shown that communication is most effective when conducted face-to-face, while detailed documentation was shown in a 2008 survey to be ineffective (see For this reason, the agile manifesto starts by emphasising "Individuals and Interactions over Process and Tools". By interactions, we mean communication. Good agile teams talk about everything. And they do it frequently and together; as a team. So how does this DSDM Atern principle manifest itself? By starting off a project with a clear (and ideally well-presented) Vision and a credible, viable business case, the team should all be aware of what they are aiming for and what is really important. This can help drive the requirements-gathering process to best effect. By including stakeholder roles in the development team, requirements are easily clarified as and when needed. User stories are deliberately kept concise in order to ensure that requirements are not documented in detail, necessitating conversations between those who ask for the requirement and those delivering the solution. By emphasising the use of modelling and prototyping to clarify understanding and ensure that the solution evolves in the direction the business needs. With facilitated workshops, the time a team invests in gathering requirements, estimating, planning, designing or problem solving is most effective. Agile workshops are more than "just another meeting"; they often replace days of time spent documenting and reviewing. By including the entire solution development team in daily stand-up meetings, everyone is kept informed of progress, priorities, risks and issues on a daily basis. By frequently demonstrating the evolving solution to the wider business community, all interested parties are engaged, involved and kept informed of progress so that they can ensure the solution meets their needs. BUT! While Atern – and all agile methods – are designed to encourage communication, there are still challenges. We have all seen those people who tend to say very little in meetings, those who would rather not "make waves", and those who are out to further their own agendas. So generating a one-team culture is vital. Workshops and stand-ups must involve everyone appropriate. That means everyone should be encouraged to participate actively. All talk should revolve around "we" rather than "he", "she" or "they". Talk openly about the cause of the problem, rather than who caused it. Agile is all about the people. Value your individuals and get them to interact effectively and you will have a much greater chance of success. Continue reading
Many years ago, as a traditional, PRINCE2 project manager, I battled with the apparently counter-intuitive demands of my stakeholders and PMO for big detailed plans up front, when no-one in my team really knew the answers. Further, I am not naturally a command-and-control sort of bloke and giving detailed task-level instructions to professional developers who knew more about their craft than I did was also very difficult for me. But when I discovered Agile and it's focus on collaboration and iterative development, I realised that it suited my natural style of teamwork. The agile project manager or Scrum 'master' is a "servant-leader" and I like that. I like how I planned at the level of detail I was comfortable with and I was instantly more successful with it. My projects were delivered on time and with delighted customers, unlike in the past where that was not the norm. I was reminded of this while reading a thread in the Agile Alliance group on LinkedIn. Scott Ambler has been gathering and publishing statistics for a while now and concludes: "there is no statistical difference (yet) between agile, iterative and waterfall, so claims that waterfall is better (or worse) than agile at scale aren't backed up by actual data that I know of." Interesting, eh? Personally I have (perhaps mistakenly) viewed "Agile" as an umbrella term for a number of methods, including Scrum and DSDM. In that context, Agile feels more natural to me, more common-sense and I have yet to find anyone who, having tried it, feels it is not better than waterfall. Whilst it is impossible to run the same project twice, I can say with certainty that in over 5 years, we have never failed an agile project, nor has one been delivered significantly late. I am hoping to start creating some metrics soon to prove how well it does work and to drive further improvements. On that subject, stay tuned. Continue reading
Why develop iteratively at all? Well, clearly because it gives us more frequent feedback loops. Developing a small chunk of the solution allows us to get an early indication that it is evolving correctly, getting closer to the business' need. But for iterative development to be successful, we need to ensure that our timeboxes are of a suitable length, and that we pause at the end of each timebox to review progress. So how long should a timebox be? The rule is "between 2 and 6 weeks with a preference for the shorter timeframe." Why is this? The optimum timebox length is a compromise between rapid feedback and having sufficient time to develop a demonstrable part of the solution, which can depend on many factors like team size, technology, solution complexity and how it is integrated with the rest of the code base. I personally prefer two week timeboxes, but others prefer three. In Atern, timeboxes are structured as follows: * Each timebox starts with a kick-off workshop, during which the team select which requirements they need to deliver, and re-prioritise them for the timebox. Every included requirement needs to be fully understood by the whole team at this time, although not all of the work required will be completely clear. At this point the team (re-)estimate the relative size of each requirement and verify their velocity. The timebox is then broken into three distinct parts : * Investigation – 10% – 20% of timebox length is spent going into the detail of each requirement to be included and planning the work required to satisfy it. There needs to be a brief review at the end of this to validate the estimate made when the timebox kicked off. * Refinement – 60% – 80% of the time is spent evolving the solution in line with the priorities set at the timebox kick-off. At the end of this there is a brief review to determine what has been completed and what work is still in progress. This allows the business to prioritise work in progress so that the most useful features are completed at the end of… * Consolidation – the final 10% – 20% of the timebox during which as many requirements as possible are completed and accepted by the business. Work that cannot be completed in time may need to be temporarily abandoned so that other work can be completed. Each timebox concludes with a close-out which comprises two parts – a demonstration of the solution as it has been evolved so far (during which the business accept what has been delivered and identify any weaknesses or omissions), and a retrospective in which the team look back on their performance. More on demonstrations and retrospectives in later posts Continue reading
It has been said that a project manager's role is to achieve objectives through the work of others. In the sense that an IT project manager rarely does the analysis, the design, coding or testing him- or herself, that is true. A project or program manager has resources assigned to him/her for the duration of the project so that the manager has some control over what happens. The only way a project manager can – or should – be held accountable for the outcome of the project, is if he/she has complete control over the elements that control that outcome – essentially, the resources and the schedule. Impose an immovable deadline and assign or restrict the people who work on it and the PM is on a hiding to nothing. From that point on, the PM is spending most of the time covering his derrière or preparing to assign blame elsewhere. Not healthy for anyone. But how, I have been thinking recently, does that differ from the consultant? What does a consultant achieve? How do you measure their effectiveness? After all, a consultant can only advise, persuade and influence. They have no people directly assigned to them to carry out whatever assignments they see fit. People in the rest of the company can choose to observe or reject the advice given. The consultant's success is entirely dependent on his powers of persuasion, his influencing skills, rather than his control over schedule and resources. My role is currently akin to that of the consultant rather than the project manager. I have no resources assigned to me to accomplish any tasks. My objective is to improve the way our organisation operates, specifically its agility (whatever we deem that to mean). This means I must influence, persuade, cajole, argue, even beg in order to achieve my objectives. I am completely comfortable with doing this. I am comfortable speaking with new recruits, or CxOs, one-to-one or in a group, making them believe what I believe and persuading them to put into practice that which I am preaching. But it's generally been up to them to put it into practice, whether they choose to or not doesn't affect me. But in my own part of the organization, I am responsible for improving agility through others. If we don't, I am at fault. This I am uncomfortable with. It is not a part of my training. I am (through training and years of experience) used to being totally in control of whatever I am responsible for delivering. Not having that level of control but still being responsible for things makes me uncomfortable. But that doesn't mean it's wrong; it just means it doesn't come naturally to me. How is my success or failure going to be measured without simultaneously considering the success or failures of others? What part did I play in those successes relative to others? It is difficult to assess. The crux of the matter, though, is that at this point in my career, I am being stretched to perform outside my comfort zone. It carries risks, but it also potentially carries rewards, not least in the shape of massive job satisfaction. I am motivated; I am determined. I will tame my tigers! Continue reading
Have you started an agile project and realised part-way through that you had made a decision early on that now needed to be changed? Did you ever deliver on time and not meet the objectives of the stakeholders? Did you find out too late that an operational team is impacted by your project and you have not planned the transition for them? I have heard and read stories of allegedly agile teams running into just such problems, and they are all symptomatic of poor planning. At the APLN session in Washington in 2009, Scott Ambler said "of course we need to do some up-front thinking!" Agile methods generally do not consider the early stages of a project. I alluded to this in my last post on project management. Assuming we still view the delivery of a solution to a set of requirements as a project, we need to consider what happens before the first development iteration. And this is where Foundations comes in. The Foundations stage of an Atern project comprises three basic areas (in parallel) *) Business Foundations – compiling the business case and an initial prioritised requirements list (PRL) *) Solution Foundations – obtaining an understanding of the high-level solution, considering system architecture, business area change and development approach and standards. Not in detail; just enough to start development without making big expensive mistakes *) Management Foundations – the governance and organisational aspects of the project, how the project is to be managed, identifying who will fill each role, how key project management practices will be applied, and creating a high-level delivery plan. How could you possibly start development without at least thinking about these aspects of a project? How much work is undertaken during Foundations is, of course, dependent on the size and complexity of the project. How that work is documented is subject to the principle that we only work on that which is useful. If a formal document does not contribute to understanding, one need not be produced. But some things are well worth capturing in some written form. Here are some examples: * Vision – capture on a single PowerPoint slide and put up on the wall of the Team area * System Architecture Definition – diagram it and put that up on the wall too so everyone can refer to it throughout the project. * Prioritised Requirements List – for audit and traceability reasons these should be captured in a suitable tool of some sort where everyone can find them. Timebox this Foundations stage appropriately, plan the work that needs to be done and review what has been done with the team and stakeholders when you have finished. Consider the question – Having done this Foundations work, is the project on a sound footing? Do we know enough to proceed with confidence? Note that cancelling a project at this point should be viewed as a success. Continue reading
I mentioned on Twitter a while ago that, although we're an agile organisation, we do employ Project Managers. To my surprise I was criticised – indeed derided – and unfollowed for it. Why, I wondered. Let's be clear, I am not advocating that an agile team needs a traditional plan-everything-up-front project manager. Quite the opposite. But let me explore what's wrong with the popular view of agile development roles and responsibilities. It appears to me that most if not all the agile literature starts with a project already approved, a team already formed and a set of requirements already set out. But how did all that happen and who was in control of it? Who formed the team in the first place? Who is it who identifies the stakeholders and manages the relationship between them? Who identifies the major risks to the project, analyses them and manages mitigating actions? Who liaises with the governance authorities? The team is supposed to be self-managing. And in the sense that they plan and manage their own work at the detail level, they are. But who does the macro-level planning? Who plans how long the project will last and when benefits can be delivered? And don't tell me the project ends when the business says it does; that's just silly. The idea that you can run a modern project with just a single business representative, a so-called "Master" in charge of the team and a self-directing group of individuals is not scalable beyond the smallest of projects. And Agile is being adopted on some large and complex projects these days. A project manager is needed because of the skills he or she was trained to employ. Planning (yes, even in an agile sense), dependency, risk and benefits management, stakeholder management, motivation and coaching. But the role definitely needs to change to suit an agile environment. The command-and-control PM is no longer welcome. Instead the agile PM needs to be an enabler. She needs to form the development team in the first place in accordance with the skills required of each role. She then needs to provide them with the big picture, the overall plan and with the direction for the detailed planning, which the team then do. She needs to be on top of progress and identify when things get in the way, removing blockages to enable the team to make progress. She needs to liaise with senior management, keeping them away from the development team so that they can make best progress. She needs to provide the team with the tools and skills needed to succeed, and lastly, she needs to step back and let them get on with it. The agile PM manages not by controlling everything the team does, but by providing direction and doing whatever is necessary to enable the team to make progress. The traditional project manager of a software development team is like the same role in a building project. The agile project manager is like the manager of a sports team. Setting out strategy and coaching the team to best effect, then when they get out on the field, leaving them to do what they do best. Continue reading
Let us first define what we mean by Quality. Atern recognises that there are two elements to quality. * Solution Quality – the solution delivers customer satisfaction. It meets the business need, and meets standards set for it at an acceptable level of maintainability. * Process Quality – the organisational standards of quality, which may range from informal guidelines to ISO or CMMI processes and procedures. Atern addresses both elements. Solution Quality. I have heard it mentioned on traditional projects that delivering the entire scope is an essential measure of quality. This is generally because traditional requirements specifications do not prioritise the requirements – it is a set. The Atern approach is to fix the project time (and therefore cost) and vary the features to be delivered in order to meet the end-date specified. Even on those projects where the user says "I don't care when you deliver it, just give me everything I want" there is scope to deliver early by prioritising the MUST Have features. The business should therefore be prepared to accept a fit-for-purpose solution, rather than one which delivered everything requested but late and over-budget. What is needed is to define early on (during the Foundations phase at the latest) the level of quality desired in terms of acceptance criteria for the solution as a whole. A key measure is maintainability – Is this a short-term tactical solution, do we need to deliver first and re-engineer later, or must the solution be fully-supported from day one? The answer to this question will drive the approach taken to the entire project and the acceptance criteria for all requirements. The risks inherent in this decision must be understood and managed. Defining acceptance criteria for each requirement (user story) is essential to drive development of the solution towards the business need. Rigorous and repeatable testing ensures that the team can prove that the acceptance criteria have been met, right up until the day of final deployment. Other practices and techniques that Atern uses to ensure a quality solution is delivered are: * MoSCoW prioritisation – keeps the team focused on the important features * Timeboxing – on-time delivery of each timebox ensures on-time delivery of the project as a whole * Facilitated workshops – ensure workshops meet their objectives * Modelling and prototyping – ensuring understanding of the requirements and the solution * Demonstrations at the end of each timebox – provide confidence that the solution is evolving to the user's satisfaction * Regular review sessions at key points – the 'inspect and adapt' so essential to ongoing improvement * Daily stand-ups – ensuring progress is measurable, the team are focussed on priorities and problems are identified early * Defined roles and responsibilities – ensure the right people are involved at the right times in the right activities. * The Foundations phase itself – ensures that sufficient up-front thinking has been undertaken to ensure that no big, expensive mistakes are made. Some of you may notice that some of these are unique to DSDM Atern. Process Quality Atern has been recognised as an appropriate approach for ISO 9001 accreditation and is used in organisations wishing to combine agility with achieving CMMI level 3 and above. My own organisation is targeting CMMI Level 3 next year. Atern provides a documented lifecycle and practices which are completely in line with CMMI processes. Key to implementing this effectively, though, is minimising the overhead and bureaucracy. All activities must contribute some benefit towards the end results. The Atern lifecycle and its iterative structure provides a perfect framework for the introduction of Gateway or Checkpoint Reviews during which key questions can be asked of the project team with stakeholders providing assurance to the governors that the project is proceeding correctly. An iterative approach also provides an opportunity to measure progress objectively, something a traditional waterfall approach does not. In summary, the fundamental principle of quality within Atern is to define up-front the level of quality desired, then engineer it into the deliverables; don't try to bolt it on afterwards. Continue reading
Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association. But challenge anyone on any project team and they will probably tell you "Of course we collaborate". But do they? Do you? Really? Any team who say they are being agile will say they collaborate, but again, I ask – Really? What we are aiming for is a team that performs better than the sum of its parts, one where everything – prioritisation, estimation, planning, development, testing – is done by the team. Together. That doesn't mean that individual roles and skills disappear; they don't. While teams will always have people with diverse skills – and they need them – it is getting these different skills and opinions together that helps the team as a whole perform better. This 'one team' culture is the essential element of collaboration. To make it work, no individual should consider him/herself more important than any other. Even the Project Manager takes on a different role (more on this in a future post). If anyone has a prominent role, it is the Business Ambassador, for it is this role that needs to make the day-to-day prioritisation decisions on which the rest of the team depend. But even then, input from other people – Business Analyst and Advisors for example – will be needed before the team can plan, and commit to delivery. So, to make this work, ensure no one in your team is making decisions alone (except the lowest level task decisions). Facilitated workshops are the tool for prioritisation, estimation and planning. The team agrees work priorities, the team estimates the work to be done, the team plans the work required and the team gets the job done. * Involve the right stakeholders, at the right time throughout the project * Ensure that team members are empowered to make appropriate decisions * Actively involve all business representatives. Build their trust * Build a one-team culture Does your team collaborate effectively? Could Atern help you? Continue reading
Atern's second principle is "Deliver on Time". What, I hear you ask, is different about that? Every project in history has aimed to deliver on time. And a lot have failed. True, but what makes Atern different is that it is specifically designed to meet this objective, provided you follow the rules. Rule 1) Define the breadth of your requirements without going into too much detail. See my previous post on Story mapping for a great way to do this. Rule 2) Estimate the relative size and complexity of each requirement (user story if that's what you're using) and derive the duration during the Foundations phase (see Principle 5 when I get there). This technique is best understood by reading Mike Cohn's seminal book "Agile Estimating and Planning". Rule 3) Utilise MoSCoW prioritisation. MoSCoW stands for Must, Should, Could and Won't Have (this time). And if you are ruthless about allocating as Must Have only those stories without which you would delay the implementation, and ensure that the total effort in the Musts is no more than 60%, you can guarantee to deliver at least those on time because you have 40% of your effort allocated to non-essentials. This is feature-contingency and it allows you to deliver the Must Have's on time. Of course, 20% or so of those non-essentials are quite important Should Have requirements, but if push comes to shove, they could wait until the next release. The remaining 20% – the Could Haves – are the nice-to-have features, the "bells and whistles" that are the first to be sacrificed when a new requirement comes in or things take longer than expected. The iron triangle of time, cost and scope must have at least one edge that is flexible, or the project is almost certain to fail. In a waterfall project the scope (the specification) is fixed and time and cost extend to meet it. In Atern, time and cost are fixed early on and the scope is flexible, based on business priority. Make sure it is the business who are making the priority decisions. When was the last time you delivered a project on time and delighted your customer in the process? Continue reading