Aterny Blog

Latest From Our Blog

The courses we are running specifically mention that "all our work is prioritised". Project teams have extended the practice of using MoSCoW prioritisation beyond user stories and are using it on defects. But whereas the rules around prioritising user stories are clear, how does one prioritise a bug? It seems that teams are classifying bugs as "Must Fix", "Should Fix" and "Could Fix" depending on the impact. I see a couple of problems with this logic: As applied to User Stories, MoSCoW priorities apply within a given timeframe. A story can be, for example, a Must Have for the project, a Should Have for the Increment, and only a Could Have at the timebox level. Applying this same structure to bugs implies that they can be re-prioritised in future timeboxes. They can't. The process of deciding on the priority of a bug takes time, it is largely subjective and implies that some will never be fixed (something the business may not be happy with). Consider this : when a bug is identified, instead of prioritising it (and going through all the negotiation that implies), why not simply ask the appropriate Business Ambassador or Advisor whether he/she would accept the applicable user story with that bug unresolved. If the answer is No, (bearing in mind that fixing it means time is not spent on other user stories instead), raise the bug and get it fixed ASAP! If the answer is Yes, don't raise the bug at all – what's the point? Teams using story points to estimate their user stories and velocity to plan their work will know that bug-fixing does not count towards velocity. Essentially, a defect is what is preventing a user story achieving "Done" status. The effort of defect management is, in itself, a waste of valuable time and should be kept to a bare minimum. Continue reading
DSDM Atern can be thought of as a Framework (the handbook calls it that), or a Method​. It comprises a Philosophy, underpinned by eight Principles and supported by defined Processes, People (Roles and Responsibilities), Products and Practices. Like any other method/framework, it is intended to be tailored to suit specific projects. But, like any other method, the processes work best as a whole. Adhering to the Principles is easier if certain Practices are followed; following certain practices is only possible when the right People are in the right roles and fulfilling their responsibilities. Here are some examples: It is unlikely that teams will adhere to Principle 1 – Focus on the Business Need – if they are not adequately and accurately prioritising their requirements. Prioritising requirements properly requires at least that an empowered Business Ambassador is a full-time part of the solution development team, and that the priorities are agreed and understood through a facilitated workshop. See how they go together? Delivering on Time becomes much more likely if the team understand what work they need to do, which requires that an adequate amount of high-level analysis, design and planning is done during Foundations, and that the output of these Workshops is documented in relevant Products. Delivering on Time also requires that the plan has some contingency, which requires that the MoSCoW rules have been followed. Being more agile means Iteratively exploring the customers' need in detail rather than specifying the detailed solution in advance. This also requires that business Ambassadors & Advisors are empowered and involved enough to allow teams to leave the details until they get to the timebox and the solution development team work together to arrive at the best solution. For an Atern project to be successful, the team, and the project manager in particular, need to Demonstrate Control. For this, they need a feasible, clear and visible plan, formulated Collaboratively, with everyone fulfilling their Responsibilities throughout the lifecycle, and Communicating clearly and continuously. It is dangerous to ignore parts of the method, unless you understand how they interact with other parts. Not assigning someone to a specific role, for example, means some Responsibilities are not carried out, which can impact on Processes and even mean the Principles are not met, which can reduce the chances of success. Every Principle that is not adequately met constitutes a risk to the project success. Think carefully during the early stages of the project about how it will be run. Take each of the Principles in turn, read them carefully (see the handbook or my earlier blog posts on each) and construct your development approach in such a way that all of the principles are met. Do that and you won't go far wrong. Continue reading
I received an email from a recruiter recently. It has been a while. Back in the days when I badly needed a job, emails from recruitment agencies were mostly of the "sorry, but…" variety. Then when I had a job, they started asking me if I wanted another one. I have been permanently employed for over five years now, and the emails offering me jobs had, I thought, stopped. Until a couple of days ago, when I received the following email: Hi Christopher, My client is one of the world's leading providers of IT solutions and services to retail banks and retailers. They have a footprint in over 100 countries. The Security Analyst will be involved in the design, definition, build and support of key management and all other security aspects related to our card production and transaction processing services. They will be required to analyse requirements, define appropriate solutions, document and manage/oversee operational procedures (including key ceremonies). Key Responsibilities It then went on to describe the required skills for the role, which I won't bore you with. None of which I have ever had on my CV. None. Ever! The email ended with: If you are not interested or this has no relevance to your current work requirements then please accept my apologies and let us know what your current situation is so I can update our database accordingly. Many thanks in advance for your time. I was astonished! Not only had this idiot offered me a job that required skills I do not possess, he knew it! And he did it anyway! Obviously this email was created by merging the job specification with names from their database. He was either too lazy to actually select people who might be even remotely suitable, and instead just spammed everyone he could. Or alternatively he was too stupid to figure out that my details as held on their database were completely different from those required for this role. I am not sure which is the scarier thought. Now some of you may get emails like this all the time. I don't. So as soon as I had a few spare moments, I replied as follows: Dear ****** The fact that you have sent this email to someone completely unsuitable for the role tells me that you are simply spamming as many people as possible in the hope someone may be interested. What you have done, instead, is given me the impression that [company] is an unprofessional and desperate group who actually pay no attention to matching demands with available skills. I hope you get lucky because I will not be recommending you to anyone. Regards I know that, because all of the above is fact, it is not libellous, and I am sorely tempted to name the person and his company. If anyone wants to know who that person or company is, I will happily provide details. Maybe it's just me but I loathe and detest spam. And that email was as unsolicited and unwanted as any offering me Viagra, porn or penis enlargement treatments. If the recruitment industry is populated by people whose only required skills are copy, paste, merge, send, then I do not want to be associated with them. It is my hope that some of you feel the same. If you do, I hope you respond in similar fashion if and when you receive similarly ridiculous job offers from stupid, lazy people. Let's see if we can raise the standards of professionalism back to where it ought to be. Continue reading
The heart of agile – it's very essence – is the principle that the best solutions come from exploring the evolving solution with the customer, rather than specifying it all up front and presenting them with the solution at the end. Are we agreed so far? Good! But this means that customer collaboration is the one key essential element that makes agile what it is. All of the other techniques – user stories, planning poker, stand-ups, retrospectives, collaborative planning, etc – are designed with this in mind. Without active and constant business involvement, they just don't work as well, and teams find themselves making compromises. Without active business involvement on a daily basis, teams are forced into getting the most out of the limited time they do have with the business by doing more and more specification in advance. This is a perfectly reasonable response to the problem of a lack of business involvement, but it does limit your agility. Look at your user stories. Are they just a single sentence in the recognised Cohn format, with genuine acceptance criteria? Do you leave the details until the time you code up the solution, when you can discuss it with the business? Or not? Being Agile is ALL about active user/business/customer involvement. Without that, you cannot be effectively agile. But you shouldn't pretend that you are, either. So what's left? If you really cannot get the required level of business involvement, you can tailor the DSDM Atern lifecycle to compensate. Start by doing more during Foundations – do more visioning, design and modelling, and plan in more detail to ensure that you can schedule business activities early and get their commitment. You might also consider the focus of each timebox: Exploration, Engineering or both. Think about how the lack of business involvement limits your velocity, and plan around that to ensure you can make best progress without leaving all your business acceptance testing to the end. Remember, the goal is still the early delivery of real business value. Continue reading
In an agile environment, where process and practice are not rigidly prescribed and enforced, ways of doing things will change. They will evolve. Conventional agile wisdom says this is a good thing, but in my experience, that's not always the case. Teams should be continuously improving the way they work, but in some cases, they simply slide back into old customs and other teams see this and copy them. Even when those practices are not working. this will be the topic of a future post. But interestingly, when it comes to an organisation split across multiple sites, these practices are like evolving organisms. When they interact, like across teams that sit adjacent to one another, the practices spread and evolve bit by bit. But because the teams at the other sites do not see this, they do not adopt the altered practice. I spent the last two days at one of our other development sites and was amazed at the differences I saw. Things that are the norm at the 'main' site, are nowhere to be found at the other. And in some cases this is a very good thing. Free from the influences of strong but misguided characters, they are sticking more or less to what they have been taught, although they have adapted them – and rightly so – due to the nature of the projects they run there. They are like the creatures on Madagascar or Tasmania – different to those on the mainland. In some cases worse and in some cases a lot better. But definitely different! Continue reading
Many years ago, when I was working as a project manager in a large corporate environment on PRINCE2-governed projects, I once had the misfortune to report a project as RED on the old Red, Amber, Green status report (I can't remember why). Those of you who have done this before will immediately recognise that, in some organisations, this is a very bad idea. And mine was no exception. The red status is supposed to signify that the project is in imminent danger of failure unless action is taken by a senior stakeholder. In that company it was seen as not doing your job properly. What happened on my project was that I was assigned someone else to 'help' me. He took over everything and put in place a "rescue" procedure. That procedure included running a short daily meeting in which all the key team members gave an update on the work they were busy with, which he checked off against my project plan. I recently had cause to remember that while chatting with a colleague on the subject of the purpose of daily standups. They are one of the two most useful agile ceremonies – retrospectives being the other. What struck me though, was that something that agilists take for granted is seen on waterfall projects as something to be introduced in an emergency. And, if it was an effective tool for a troubled project, why would it not be standard procedure on all projects? Project managers who run daily stand-ups have told me that, even if they were told to go back to the old days and use a waterfall method, they would still hold a daily stand-up. It's a pity that those who have not been exposed to agile have not had the opportunity to see the benefits it can bring in terms of being in full control of a project. A daily stand-up on a waterfall project? Why not? Continue reading
I have been to the last three or four conferences, and I believe this was the best in terms of quality of content and quality of speakers, completely discounting myself of course. Which is a pity, because attendance was down this year. I hope that more people attend next year because I learned tons! My biggest regret, as always with these things, is that I can't be in two places at once, so one has to prioritise which tracks to attend to get the most from the event as a whole. I focused on the Agile at Enterprise Scale track, although I dipped into the Inspect and Adapt and even the Agile for Public Sector tracks On day two (I did not attend the first day), I learned about PANDAs. No, not the cute and endangered species of bear, but Poor And Non-Disciplined Agile. I learned about the System Error report and what is happening with agile in the public sector – some very exciting developments, although they appear to still have a number of significant challenges to large-scale adoption (saying "Make it So" doesn't always work on it's own). I attended Margaret Morgan's workshop exploring the implications of focusing on maximising utilisation and the (negative) effects that has on team productivity. The relay race demonstration was an interesting way of showing the effects on the total amount of work delivered, but while I grasp the concept, I would have difficulty explaining it. On the third and final day, Ivar Jacobson presented a new perspective on Lean thinking and the concept of a method and practice-agnostic pattern that can be universally applied to all software development. See for details. I found it fascinating and could have easily discussed the topic in more detail for hours. I thought Andrew Griffiths presentation of a structured method for Agile process improvement was very interesting. I wish I had known some of that two years ago, but I will certainly learn from it and try to put the principles into practice. For people who think even planning poker takes too long, Peter Measey presented a short workshop on magic estimating. It's similar to what I called matrix estimating a couple of years ago, but even faster. I still have questions about it's effectiveness as it appears to have pre-requisites to make it work. It also assumes you will do more detailed planning later, but for rapid can-we-do-all-this type planning, I think it's brilliant and can't wait to try it. Jean Tabaka (say Ta-baker) gave an inspiring talk on an Agile Community of Thinkers, which gave me a lot to think about. The DSDM Consortium should be congratulated on another fabulous event. I especially liked the fact that the first day (which I skipped) was dedicated to those new to Agile or contemplating adopting it. The venue, the Inmarsat Centre, was perfect, and the organisation and catering was superb. It was lovely seeing some familiar faces there again, and great to meet a few new people too, not least Jean Tabaka herself. Pity I missed Arie van Bennekum, Agile Manifesto signatory, who gave a talk on day 2 at the same time as the utilisation vs productivity one. On a final, selfish note, I would like to thank Andrew Craddock, who helped me pull together and present our talk on Agile Governance. I was astonished at how many people attended. So many in fact that we had to move to a bigger room, and still had standing room only. Looking forward to next year already. Continue reading
I recently attended a timebox retrospective of a team I have started coaching. The team have been together for some time now and are constantly improving their performance. But one issue that came up (there were others, about which I will write more another time) particularly interested me, because it highlighted the different attitudes and prejudices at play in a team. At present the team are split in two, seated at opposite ends of the building. The project manager is located in the building next door. Not ideal. They have, to their credit, been asking to be co-located for some time, and it was announced that they will move next week, to two adjoining clusters. The dilemma they face now is obviously who sits where. They have, bizarrely, been allocated seven workstations across these two clusters – three at one cluster of three desks and four at a cluster of six. The team comprises the project manager, business analyst, four developers and two testers. Eight into seven doesn't go, but who to sit with whom? After some discussion I chipped in with the following question: A team locates developers together when there is a need to share application domain knowledge. A team locates developers with testers when there is a need to improve the quality of the code being delivered to the customer in each timebox. What, I asked, is more important to you. There was silence for some time before they decided to think about it. They move on Tuesday. I await their decision with interest. What would you do? Continue reading
For months I have been offering help to teams who might need it – coaching, training, facilitating, whatever. I can't be dictatorial because that will just antagonise the team. So I need to get into the team and help them help themselves without stomping all over them. Mostly, though, the teams seem to think they don't need any help. But then, last week a lead developer came to talk to me. He had just joined a new team and had found 'challenges'. We talked for a while and I made some notes. I suggested that we talk with his project manager about what I could do to help and yesterday the three of us got together for what proved to be an interesting conversation. Possibly their biggest problem is that the sponsor/visionary of their project leads a very small team of very busy people. Even the most capable of them is not suitable for a Business Ambassador role, and the Sponsor himself doesn't have the time to be involved that much. So, the Business Analyst is the proxy customer. A big risk. But one the PM assures me that the Sponsor is willing to take, partly because he cannot recruit any more people. In their first timebox they failed to deliver even the Must Have requirements. One user story was estimated at 50 hours – yes, hours – but took more than double that, proving once again how estimating in hours is notoriously inaccurate at that level. And the story was too big anyway. The team is not co-located either. One half of the team is at one end of the floor, the other half about as far away as possible without being outside. And the Project Manager himself is in the building next door. The developers and testers are also not sat together, although the PM did suggest it. The developers believe that sharing the scant domain knowledge available is more important than having the testers sat with them. A fair point, perhaps? Having just that day finished their first timebox, I asked if I could attend the retrospective and the planning session for the second. "I haven't planned a retrospective," he said. And that concerned me even more. Largely, it's due to the lack of available space to hold them. Meeting rooms are all booked up, he said. Probably because he hadn't booked recurring appointments for every timebox before kicking off the first. I will be spending some more time with this team over the next few weeks to see if I can help. While some of their challenges might be insurmountable, I am sure that they can improve their predictability. This should be interesting. Continue reading
I recently had a conversation over breakfast with a number of senior and influential people on the subject of measurement and reporting. The talk centred around the question of how organisations can report on their agile projects effectively. Or, more importantly, communicate about them. Why is agile reporting so special? Well, clearly an iterative approach to development provides an opportunity for measurement at regular intervals. And traditional reporting of percentage progress against set milestones is neither appropriate nor accurate. Surely this is easy, I hear you say. We have story points on all our stories and we have burndown charts that show how much we deliver every timebox. Easy! Well, the people in the room didn't see it that way. You see, the CFO and the business leaders don't know what a story point is and don't care either. "Burndown? Sounds dangerous to me." What they care about are what they are going to get, when they are going to get it and how much it will cost. Apart from being inappropriate for agile projects, the problem with traditional progress reporting is that it is almost entirely subjective and biased. Some project managers are strongly incentivised to report good news, as the IT department cannot be seen to be doing a less-than-perfect job. Some companies have people whose job it is to turn red status reports into green ones. Not by changing what's going on, just by… aggregating and filtering the reporting before it gets to the upper echelons. Not only ineffective, this is downright destructive. So we need some objective reporting, based on real data, right? Yes and no. While agile methods provide an opportunity for regular objective – and subjective – measurement, there is still the need to have a conversation with the senior stakeholders. They do not want a lot of numbers and graphs that they don't understand. As I mentioned earlier, their needs are simpler. In some cases, this problem is exacerbated when a contract is involved. Despite the agile manifesto being ten years old, many organisations it appears, are still struggling with client-supplier contracts that protect both parties involved while still permitting the flexibility and collaboration that is needed for agile projects to succeed. How do you report to your client how much of the scope you have delivered when the user stories keep changing? So we really need to balance the need for truth, objectivity and the avoidance of 'spin' with the need for clear and simple status updates in a form that everyone can understand. Perhaps the answer lies in the concept of "Feature points" or "Epic points". It relies on the fact that requirements only change at the detail level; at the highest levels they remain stable throughout the project. If you state the vision for the project in a single sentence, then decompose that into the next layer of requirements you will probably have anywhere from a handful to a couple of dozen high-level Epics. Each of these is likely to be a Must Have. It's when they get broken down further and the detail emerges that lower priority requirements emerge. If our measurement is based on data at the detail level, it changes too much to be meaningful. And we do NOT want to advocate fixing those requirements up front just so we can measure how we are progressing. So let's take those high-level Epics and somehow measure them – in "epic points" if you like, and report on those as and when they are delivered. This way, we measure and report on what the business care about, objectively, and without spin. Either it has been delivered or it hasn't. The key is in defining those high-level epics. There needs to be enough of them to make regular reporting feasible and allow extrapolation of progress across the entire scope. If it took one month to deliver 20 epic points, then it should take another four to deliver the remaining 80 epic points that constitute the rest of the project. And we can flex the features at the detail level to accomplish this. During the summing up of the session, one chap mentioned that this was cutting-edge stuff and very few, if any, organisations are doing it well. The key, as with so many other things, lies in communication. About requirements, priorities, estimates and not least of all, risks. I would be interested to hear from anyone who has got this stuff right at the organisational level and is willing to share their experiences. Or from anyone who has anything else to contribute to the topic. Continue reading