Aterny Blog

Latest From Our Blog

I am a huge fan of using the physical index cards to represent Agile requirements in the form of user stories. I have in the past used them to very rapidly re-prioritise a requirements list by moving the cards about on a table. Seeing the cards up on a story board and their movement across the columns is a brilliant way of showing progress and focussing the stand-ups. There is also no substitute for the physical cards when estimating (whether you use planning poker or an alternative). But there is one situation when I have found that the 'purists' view of using the physical tokens (the cards) is not as efficient as using whatever tool you use to store and manage your requirements set, in our case TFS. I tried doing timebox planning by laying out the cards for the rest of the project on a table and asking the team to select those which were required in the upcoming timebox and to arrange them in priority order, into three columns – Must, Should and Could. The problem with this is that, with a large number of cards on a table, it can be confusing, and seemed to generate a lot of discussion as people on one side of the table talked about one story while two other people discussed another. Getting decisions was like pulling teeth. And when we finally did, the resulting notations had to be transferred from the cards themselves into TFS, opening up the possibility of human error. We have since reverted to what other project managers have been doing for a while – using TFS directly. Having the tool (or an Excel view of it) open on the big screen monitor on the wall, we walk through the list, line by line, deciding on its priority and occasionally re-sizing them, as well as allocating them there and then to the timebox being planned by updating the iteration path field, making the update real-time. If the person in charge of the keyboard types something incorrectly, the rest of the team are quick to shout out the error too. By the end of the session, we have the stories we want all allocated to the correct timebox, with appropriate priorities and sizes. It's not as much fun as playing with cards, but it works. I'd be interested to hear your experiences on timebox planning using physical cards Continue reading
If you are in an agile team and don't use user stories, you are probably in the minority. But if you do, are you finding that they are always the best way of capturing requirements? I have recently come to question the typical format of a user story and its suitability to all requirements sets. The committed agilists among you (and I count myself as one of you) might, at this point, be starting to splutter and spill your coffee, but please… hear me out. All else being equal, user stories are the best way of capturing and managing requirements that I have come across. But… there are one or two situations in which their use is potentially compromised. The "As a… I want…So that…" format (or variations of it) has been around for a while now and has become commonplace. But have you ever found it difficult explaining the "so that…" part? Take a regulatory project, for example. All the stories are " so that we comply with the legislation". Not especially helpful, is it? But even if all the "So that…" clauses are the same, what are the implications in dropping that part of each user story, leaving just the "As a… I want…"? Probably not a lot to be honest, but does that make it no longer a user story? As long as it is clear how the individual stories contribute towards the goal of compliance, then I don't see a problem. But is there then a better format for user stories under these circumstances? Or should we be using something else instead? Let's look at another aspect. User stories also work best because they deliberately defer the detail of each requirement until the team starts working on it. This is only possible because you have a Product Owner / Business Ambassador around to provide the detail behind the requirement as and when necessary. But what if you don't? What if your Product Owner isn't around for more than one day a week and even then you have to collar him between meetings? I know some of you are shouting "Get a different Product Owner", right? In an ideal world, yes that might be the answer, but his replacement may be equally as busy and may not be as knowledgeable. So, let's say you're stuck with the guy you have. Do user stories still work as well? Not really. The limitation is in the deferral of detail concept. As noble an idea as it is, that is not always possible. The less active business involvement you have in the team, the less you can rely on vague or woolly user stories being sufficient to capture requirements. When the rest of the team need to be able to just get on with the coding and testing without the business being around, the requirements need to be more detailed, don't they? More like little specifications, in fact. Here are some options: expand the "I want" part of the story to provide more detail, attach supplementary materials (models, mock-ups, annotated screen grabs etc) expand the acceptance criteria into full Specification by Example scenarios Or has anyone come across a format for a teeny tiny specification that still meets the INVEST criteria (although without the Negotiable bit – IVEST)? Continue reading
I was asked to take one of the speaking slots at the "Agile in the Finance Sector" conference in London on 7 March. It was a great event and I was privileged to be asked to speak. My talk was entitled "Barriers to Agile Adoption and Improvement", and having spent a fair amount of time preparing it, I was really pleased to get some great feedback via Unicom on what the audience thought of my talk. Here is a short interview in which I was asked about the day. My average approval ratings were: Value 86% Content 89% Presentation ​86%​ ——– Overall 87% Not bad for someone who doesn't do this sort of thing for a living. Perhaps I should, eh? But it got me thinking. Feedback is always valuable, good or bad. It is at the heart of Agile, after all. I remembered receiving a few very gratifying emails over the last couple of years on presentations or training courses I have run. This sort of feedback is always welcome: Once again many thanks for this outstanding training session which exceeded all participant's expectations (and they were high!) Overall – excellent! Content – sufficient to gain understanding of the concept and how it works, and its value to the business if adopted properly. Trainer skills – engaging, easy to understand, able to answer questions, able to facilitate discussion around the subject. Relevance – totally! Thoroughly enjoyable session, and if you need my skills on your team ever, if there is a role, you have a new recruit here! I totally believe in this approach, and I would love to be more involved. You have an excellent way of keeping everyone engaged – especially with 28 people to manage. You used a lovely mix of techniques to draw out multiple thoughts from very different people Thanks. I thought the session was perfectly well presented and its content was both inspiring and concise. Wealth of information. And my personal favourite: After your training I felt very motivated and incentivised. I now wish to work in IT Development as well and hope to learn even more and get involved in as many projects as possible. Very eager to use Agile and spread the word to others. I enjoy training and speaking on a subject I care deeply about. And it makes it doubly enjoyable when other people get enthused by what I'm saying and showing them too. So the next time you attend training or a meetup or a conference, please provide the speakers and organisers with your feedback. I'm doing another talk soon at the Agilia conference in Brno, Czech Republic. Looking forward to it. Continue reading
Over the last few years, I have been asked a few times variations on the question; "What projects are suitable for agile, and which aren't." It's a fascinating question, and one I think has a relatively simple answer. It depends. It depends on how much you have of two specific things which are absolutely essential for agile to work, however you define what Agile is – active business involvement in a cross-functional team, and flexible requirements prioritisation, i.e. not all requirements are Must Have. If you have a very actively-engaged Business Ambassador (Product Owner in Scrum terms), and less than 60% of your requirements are Must Have essentials, you can afford to be agile, and you can set your project up accordingly. In other words, you can afford to defer exploration into the details of requirements and the solution until the last responsible moment, because the business is there to have those discussions and you have contingency to play with if your estimates are not spot-on, so you can plan at a higher-level, start earlier and develop iteratively. But what if you don't have those things? We have coined the term 'specification-led' which means that the business or technical environment around your ​project is such that you are not able to be fully agile, and that you are forced to do more up-front specification than would otherwise be ideal. A 'fully agile' project is one : · that has daily active business involvement, which allows the solution to evolve to meet the business need, · that has feature-contingency in the shape of sufficient Should have and Could have requirements. · in which the project can integrate and test the evolving solution frequently. It is important to plan your Foundations stage based on the answers to the Project Approach Questionnaire, so the first thing to do – during the Feasibility phase – is to complete the PAQ. This should give you an idea of the environment you are operating in. Project Managers are advised to always try to establish the most 'agile-friendly' environment possible. Any compromises constitute a risk to delivery and these should always be escalated for resolution or mitigation where necessary. Having said that, if you don't have that ideal environment, what do you do? Fortunately, the DSDM framework allows this sort of tailoring (indeed encourages it), but here are a number of things you might need to do. You will probably need to spend more time in Foundations, driving a little more certainty around business processes affected, the technical design and such-like. Risk identification becomes more important and plans will necessarily become more detailed to mitigate some of those risks. Consider doing more modelling of things like Customer Journey, which should be agreed with the customer as part of Foundations. With your Business Ambassador / Advisors not available on a day-to-day basis, you will need to be a lot more clear about the requirements during Foundations. You will probably need more of them and in more detail than would otherwise be ideal. Within each timebox, agile teams spend some time at the start Investigating the details of each story with the business. Without the business involvement this requires – and the additional detail in the user stories mentioned above – the Investigation part of the timebox need not be so long, and will mainly be focussed on technically drilling down to task level. If the project has too high a percentage of Must Have requirements (more than 70% Musts poses an increased risk), you need to find contingency elsewhere – your 'Plan B', in case the project encounters problems. Think about adding an additional timebox to the Delivery Plan to give you time contingency, and/or add additional people to give you Cost (people) contingency… from the start of the project obviously. Having no contingency is not acceptable. If business acceptance of the solution is a problem, resulting in fewer stories being completed within the timebox, you might have to plan for longer timeboxes to give you more time to get developments tested and accepted. This is especially true of things like documents that require an extended approval process. Plan in additional time for getting customer acceptance from the (often external) customer, who may have to pass several layers of approval within their own organisation before they can sign off what we've delivered. Consider the use of "surrogate" Business representatives – far from ideal but still better than running a full-on traditional project and relying solely on a specification. Surrogates need to know the customer and their requirements well – well enough to make informed day-to-day decisions to keep the project moving forward, even though the formal final customer acceptance of stories may be delayed to one or more timeboxes after the stories have been completed. For example a "surrogate Visionary" could be an account manager, a "surrogate Ambassador" an account exec. During the project, continue to press the customer for on-going acceptance of the solution, even if this is running behind development – it still decreases the risk of delivering the wrong thing at the end. Thinking of DSDM as a flexible framework that can be tailored to any project is the answer to the question I posed at the beginning. It doesn't really matter which projects are suited for Agile, we can always tailor DSDM appropriately. Remember though, that you are still striving to be as agile as possible, and it may be more than you initially think. With thanks to Dave Lyon and Barbara Roberts for their help with this article. Continue reading
Mary Henson of the DSDM Consortium asking me and colleagues about the #DSDM Advanced Practitioners #certification at this year's Agile Business Conference #agile Continue reading
How do you go about generating the requirements on your agile project? Does your Business Analyst go around interviewing each of the business stakeholders? Do you hold one or more workshops where stories are written in a group? If you have more than one workshop, how do you then de-duplicate stories? Or do you not do that at all? And when you have, how do you know that you haven't missed something important? It is important that, during the process of requirements elicitation, you capture stories at a high-level that describe the full breadth of the project (or product) scope. It is perfectly reasonable to expect detailed stories to emerge during the project, but they should not be new requirements, they should not add to the scope. Any newly-written stories should arise from breaking down large stories captured during Feasibility or Foundations stages. Ones that describe a new business need not already covered by existing Feature or Epic stories should be very rare, because new business needs will impact on your ability to deliver on time as you have not planned for the work involved in meeting them. So how do we ensure that we capture the breadth of the scope early on? The answer is two-fold: · Define the Vision and critical success factors of the project · Requirements Modelling Having an overriding vision – an objective – for a project can help focus the team on what is important and help clarify many lower-level priority decisions later. Modelling is one of the key agile practices in DSDM Atern. DSDM does not dictate any specific modelling techniques, and I am not going to, either. However, what I am strongly advising is that you do some up-front modelling in order to build some context from which to create your user stories. Scott Ambler has written about the need for this and spoken about it at least once that I know of. The larger the project, the more the need for modelling, for envisioning, for high-level design. This is not Big Design Up Front (BDUF). This is Enough Design Up Front. Being Agile does not mean being infinitely flexible. It means delivering a solution that demonstrably meets the business need quickly and with the requisite level of quality. In fact, quality is usually more important than speed. Your requirements models can be anything from a simple context diagram, through customer journey maps, process flows, use case diagrams, domain models…. the list goes on. As a rule of thumb, start with the high-level and then drill down into successively lower levels of detail as and when you need it. From this context, you can then write user stories that define the features modelled. Happy modelling Continue reading
I was once asked to help a small team adopt agile practices and improve the way they worked. I was glad to help but needed a place to start. What, I wondered, did the team need help with. At a meeting with the senior business manager, he told me their primary problem was one of quality. They don't have too many of what we might recognise as projects, but instead regularly deliver to production a number of largely unrelated small changes. What the business manager told me was that what was delivered to production often bore little resemblance to what had been requested. Why, l asked. Because when the change request was submitted, it disappeared into an IT 'black hole' and no one saw it again until it went live. Ah Hah! What they were expecting me to do was implement agile practices and behaviours within the existing team. What they needed, however, was what is at the heart of Agile, and is one of the principles behind the Agile Manifesto – "Business people and developers must work together daily throughout the project." Short introductory meetings with the managers of each of the business areas showed that only recently had they had any direct contract with the IT development team, their new project manager being largely responsible for the positive change. They were all immensely pleased with this and when I suggested that they provide "business owners" for each required change, they all enthusiastically agreed. Since then, I have provided those new business owners (Business Ambassadors) a one-day overview of agile principles, behaviours and practices and the need for collaboration and frequent communication across all roles. It was apparently well received and they will shortly be attending daily stand-ups, requirements gathering workshops, planning sessions, demonstrations and retrospectives. They will soon be an integral part of the development team and ensuring that every requested change meets the acceptance criteria they themselves define. I look forward to seeing this teams future efforts. Continue reading
My first foray into operating as an Atern coach has been more enlightening and challenging than I had imagined. A while ago, I started working with a team implementing changes to comply with two separate pieces of legislation. Typically, the project had started late, and time was running out. So you'd think that, with the pressure on, they would be looking for every bit of contingency they could find, right? And that they would be rigorously planning their scope and prioritising their requirements to generate some feature-contingency? And for those of you thinking "it's regulatory, of course the requirements are all Must Have", you're not necessarily correct. More on that another time, perhaps. But looking at the Requirements List, it was clear that the team had written 'stories' that more closely resembled a list of tasks. There were very few actual business requirements. So I had a short workshop with the Project Manager, the Business Ambassador and the Business Analyst in which I showed them the difference between a requirement and a task [I shouldn't have to explain that to a BA], and we worked through a few examples and reworded them. I think they understood why user stories are structured that way. And yet…. I later sat down with the project manager and we spoke about it. His belief was that Agile is suited only to what he refers to as 'green field' projects. And that end-date driven projects cannot be agile. And that the developers cannot estimate without certainty about the solution. Those are his beliefs! And given those beliefs, it is hardly surprising that the team were allowed to specify the solution in some detail at the start of the project. The implications of this should be obvious to you. They have removed from their project two things we as agilists firmly believe in – business engagement and feature-contingency. Their Prioritised Requirements List is essentially a list of the Must Have things to be done, so there is fixed scope as well as time and cost, and with those 'requirements' actually specifying the work to be done, the business have no further role to play in evolving the solution to meet their requirements. This was now a waterfall project, with a sizeable risk. I have my work cut out! Continue reading
Google "agile software development" (and by the way, any company that gets their name turned into a universally-used verb has seriously 'made it') and you will find literally hundreds of thousands of articles and blogs telling you exactly how to be "truly" agile. Read a bunch of them and it is perfectly possible to get confused by it all. So many different opinions exist (and some are in this blog too) as to the 'right' way to run a stand-up or write user stories or improve your team's velocity…. it is all too easy to conclude that there must be a right way if only you knew what it was. And why that advice doesn't quite seem to fit the project you're working on. There are a lot of people out there – you may be one of them – who are struggling to make agile work the way the 'experts' say it should. And through a lot of reading, a bit of speaking to people – a number of whom work in the same company as me – and a lot of thinking about it, I can offer at least one good reason why this is so. To quote Wikipedia: Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change The underlying concept behind agile is built on two beliefs: The best solutions comes from collaboration, especially with whoever represents the customer or end-user We rarely, if ever, build the solution exactly right the first time From this we can reasonably conclude that there is (at least) one essential ingredient that determines your ability to be agile, the degree of agility that can be achieved on your project. That ingredient? Active business involvement. In an environment where you have someone from the business area/s affected who has the desire, authority and the knowledge to accurately represent the end-users and strongly influence the priorities and the direction the project takes, you can be very agile. In this environment you can write user stories that describe a discrete business need while omitting the detail of how that need should be fulfilled, in the knowledge that the Business Ambassador (Product Owner in Scrum) will be around to help evolve the solution through a series of iterative development cycles. There is a lot of exploration of requirements going on in each timebox. There is much less certainty about what will be developed until the last minute. But, in this environment, the right solution will evolve. Now consider a situation in which you either have no Business Ambassador / Product Owner or that person is not always available. This is often because business representatives have 'business as usual' work to do as well, and there is a common perception that seconding someone to a project team for three, six, nine months will erode their business knowledge. In this situation, requirements definition and decisions on solution options and prioritisation are left to someone else. Someone less qualified to make such decisions. The development team are forced to get more detailed requirements up front and specify the solution a lot earlier and in more detail, because the business guys won't always be around to discuss options and review the evolving solution with the developers and testers. The lifecycle becomes more specification-led, rather than exploration-led. It becomes more 'iterative waterfall'. This is a natural reaction to the situation, and is not 'wrong'. The thing to remember, though, is not to get into this situation by accident. It is important for the project manager to identify at a very early stage whether she can get sufficient active involvement from the right business people or not. Yes, do everything in your power to secure the right people to allow your team to be as agile as possible, but recognise that if that is not feasible, you have to plan accordingly. Continue reading
Let me start by saying I am a football fan. Specifically, a Chelsea fan. Now before you all start hooting derisive comments about our captain, money or Russians, let me ask you this : have you ever considered the parallels between the manager – also sometimes known as the head coach – of a top-flight football club, and the manager of an agile project team? No? I have. Those of you who follow the sport will know all too well that, after just nine months in charge of the team, Andre Villas Boas (AVB) was sacked by the club following a string of poor results. To put this into perspective, this was the same man who, in his second year as a club manager, took Porto to the league and cup double and won the Europa league. He clearly knew how to coach a team to success. So, why did it all go wrong? As this article explains better than I could, it was not his tactics that were at fault. In fact, in the early games, he demonstrated an astute grasp of tactics that won four of his first five games in charge. No, his problem was his failure to understand why his old mentor José Mourinho was so successful – his people management skills! Mourinho can be an abrasive character at times, but he loved his players and they loved him in return. He spent time with them, he got to know them and understand them. He understood not only their footballing strengths and weaknesses but what they were like as people, and their position in the dressing-room hierarchy. He stroked egos and kicked arses with equal skill, when either was required. In short, he understood that football is not a game played by pieces on a tactics board, it is played by real people with feelings and (admittedly inflated) egos. Roberto di Matteo understands this too, and this is why he has taken the team to both the FA Cup and Champions League finals as "interim" manager. Have you noticed how much happier the players are these days? How much he celebrates and commiserates with them? He understands that his job is to get the best out of the team as a whole, not to establish his authority over the senior players, as AVB tried to do. It is no coincidence that the team's performance has improved since di Matteo took over. An agile project manager has a similar role – to understand the people in the team, to know their strengths and weaknesses and to ensure that they are in a mindset that ensures that each individual is totally committed to the goal of the team as a whole. When football players sacrifice an opportunity for personal gratification by gifting another player with an easier shot at goal, you know he has the team at heart. When a project team member helps out others on the team in order to drive greater quality or team productivity, you can tell they are operating effectively. It is all too easy to think of people as coders or testers or business analysts, but each member of the team should be thinking of themselves as a member of a Solution Development Team. And it is the sum of the work of the team that is important, not the productivity of an individual. Get the team working well together and watch their performance improve! Continue reading