Aterny Blog

Latest From Our Blog

I sometimes look at a product and wonder: "What were the requirements for that? Who thought it was a good idea?" One such product is SkyGo. It allows Sky subscribers to access live satellite tv on their laptop, tablet or smart phone. Brilliant, you might think. But while watching SkyGo on my tablet in bed this morning, it occurred to me that the only people who are so privileged as to enjoy this service are already subscribers and in a wifi zone with decent download speeds – and public hotspots in the UK do not (yet?) qualify. So they are either at work, and they should be busy doing… ummm.. work, or they are at home and almost certainly have a big telly connected to a satellite dish. So this marvellous – and yes, I think it is – product is being used by people either too lazy to get out of bed and get dressed, or have someone else watching a different channel on said telly. Further restricting it's appeal is the fact that, so far, only sports and movie channels are available, although there are apparently plans to widen this to others in the future. If I was the Business Ambassador for the SkyGo project, I might have the following requirement: As a customer who cannot access a satellite-connected tv, I want to access Sky channels online. Of course, the above is just my opinion and I am happy to be corrected. Anyone working for BSkyB care to comment? Continue reading
I have been asked to help with a workshop being run by a team of people doing some business change work. "Introduce them to the Atern way of working," I was asked. Intriguing. DSDM originated on software development projects but recent versions, especially Atern, have been written with non-IT projects in mind. I have, however, never used it outside of software development. So how, I am wondering, will Atern techniques, roles and practices translate? How do we define MUST Have requirements, for instance? How do we estimate the work involved? How do we plan? I have a number of ideas, of course. I am presenting an overview of my suggested approach to the team on Monday, as well as facilitating a requirements-gathering session. It should be interesting. Continue reading
The objective of each timebox is to deliver an incremental subset of the solution. Deliver. I will repeat that – deliver! To your customer. That means the person/s who raised the requirements initially should be able to use (at least in a test environment) the features created during that timebox. Obviously all of the Musts, and hopefully all of the Shoulds. In this context, anything that is partially completed or untested is effectively useless. Each timebox therefore must include the testing needed to ensure that the features coded actually work. Testers are traditionally trained to plan, write and execute a series of tests against a software application or product in order to find any defects. In an agile team, that job changes hugely. Finding defects is no longer the goal. Instead the software tester's primary goal is to deliver working software. Wait a minute. That sounds suspiciously like the developer's job. Or the Project Manager's for that matter. You're absolutely right. You see, in an agile team, we all have the same objective – delivering working software to the customer as soon and as frequently as possible. Time spent finding and fixing defects is waste, and we want to waste as little time as possible. The agile tester's role is as much about preventing defects from arising in the first place as it is about finding and managing them afterwards. To illustrate how the testers role has changed, I will compare a fictitious traditional tester – let's call him Dave – operating in an agile team, to an agile tester – Susie – operating in the same team through the different project stages. During requirements gathering workshops, Dave would be sitting quietly listening to the Business Ambassador and Advisors listing their requirements, and to the development team asking questions to ensure they understood each one sufficiently to start development. He might be making notes that would later help him remember what test cases to write. Susie would be checking that each requirement, as written (as a user story) was testable, by asking the business how they intended to 'sign off' each requirement; how would they know it was done. These acceptance criteria would then be written on the back of each user story card. When it came to estimating the work, she would ensure each estimate included the testing effort. This is important to ensure that each story is delivered tested within the timebox. Dave writes up his test cases and scripts them while the developers are coding. After all, he cannot test until the development is complete. Susie, meanwhile, sits with whoever raised the requirements – and possibly the business analyst – to turn those acceptance criteria into Scenarios. What this does is obtain a clear understanding of the desired behaviour of the feature under discussion. She then adds these scenarios into the test tool as executable tests. She will sit with the developers, helping them to understand how she will be testing each story, helping them write their unit and integration tests to ensure that each change made accurately reflects the business need. Dave waits until the developers deploy a set of features into his controlled testing environment. He then starts running through his test cases. As he tests, he finds defects – and after three weeks worth of development, there are quite a few of them. He raises those defects and assigns them to be resolved. He will now wait until the fixes are deployed so that he can re-test. In the meantime, his test cases are marked as Failed. Susie starts badgering the developers on a daily basis for something to test. She wants the smallest possible testable piece of functionality at a time, because she knows that the smaller the item deployed, the less chance there is that it contains defects. And the quicker it will be to find and fix them. So when code is deployed into the integration environment every day, she immediately runs the tests pertaining to the scenarios written for the stories just deployed. As she finds defects, she talks to the developers about them so that they can be resolved immediately. The tests that she runs are integrated into a regression test suite which is run as often as is needed, ideally every time code is checked in. As you can see, the big difference between Dave and Susie is that Susie is by far the more proactive of the two. While Dave is focussed on defect management and resolution, Susie's focus is on defect prevention – a subtle but important difference. The agile tester needs to think about things in a different way. If you are a tester, ask yourself: • Do we all understand the business need that this requirement represents? • What's the smallest part of that feature that I can test? • How soon can I test it? • How can I help ensure that it works the first time it's delivered? Continue reading
Apart from Agile improvement, another current focus of mine is measurement. My team has been charged with measuring the performance of the IT organisation to understand where we are, baseline it and help drive improvements. I am no scientist or statistician and I know very little about metrics. So I am trying to learn. I have of late discovered some good news and some bad news :- The good news is that anything can be measured The bad news is that you get what you measure. Doug Hubbard's book is currently teaching me more about the first point, and a recent Qcon talk by Liz Keogh reinforced what I already knew about the second. As a result of watching that talk, I am now reviewing the things I think we should be measuring and thinking about how to game it – how people will behave differently knowing that certain things are being measured. Since the goal is improvement, not the reinforcement or introduction of negative behaviours, we need to exercise some care. Continue reading
I was in London today doing some CMMI mapping with a chap who is familiar with the model, as well as our implementation of Atern. It was a pretty productive day, I think. I find it so much easier to think when I have someone to bounce thoughts and ideas off of. I am trying not to take the model too literally, focussing on the objectives. What we are doing, therefore, is looking at the CMMI-DEV v1.3 goals and practices at Maturity Level 2 and trying to work out what practices we already have in place that would meet them. For example, when it comes to Project Planning (PP), standard practice 1.1 says: "Establish a top-level work breakdown structure (WBS) to estimate the scope of the project." So do I need to define a WBS for all the activities I plan for my Agile project? No! What I am suggesting is that a set of user stories (at varying levels of granularity) that covers the breadth of the project scope along with something that defines the architecture and hardware needs will cover it. And we already do that. Another example – standard practice 2.4 states : "Plan for resources to perform the project." Well, Atern has a number of standard roles and specific responsibilities. So I have created a simple Excel template that lists the Atern roles (allowing for multiple people to fill applicable roles) and provides a column for the name of the person fulfilling each role and a note on whether they are suitably skilled or need any training. Each project is then required to demonstrate by the end of the Foundations stage that they have all required roles filled with suitably skilled people. Simple. These ones are easy. But some are proving a little more difficult to interpret, or find suitable equivalents. Take Configuration Management (CM) for example. As applied to software, CM is probably more important on an agile project that a waterfall one because of the numerous, frequent integrations of code. But as applied to other 'artefacts', it is less so. We have fewer documents to start with, and we are not so obsessed with "change avoidance." So what do we do to satisfy practice 2.4 : "Track change requests for configuration items."? The entire concept of change requests is born from a waterfall mindset – that we plan and specify in detail and then carry out the plan. Agile doesn't do that. Agile embraces change. Change requesting, impact analysis and approval can all happen in a few minutes in a workshop environment. So we are still working on that one. What we absolutely do not want to do is create a change request and approval mechanism that adds no value to the way we work – that would be counter-productive. As I have stated before, we are looking at CMMI only because it seems to hold some value as a model for improving the quality of what we deliver and the control and predictability with which we deliver it. The objective is not a rubber stamp. We are getting there. Continue reading
During a presentation recently, I was asked how an agile project team manages change control. How, the questioner wanted to know, do you deal with new requirements, scope creep and what happens when requirements turn out to be a lot bigger than you expected? Well I can tell you how Atern deals with it. But first there are a few things you should keep in mind : An Atern project has at its heart the concept of fixing the end-date and 'managing' the features – the prioritised requirements list – in order to meet this date. In order to deliver on time, we need contingency. That contingency is provided in the shape of non-essential requirements; our feature-contingency, if you will. These are the Could Have requirements MoSCoW priority pertains to specific requirements and for a specific timeframe. A single requirement can be a Must Have for the project, a Should Have for the first Increment (Release), but only a Could Have for the first development timebox. The business case for the project assumes that at least the Musts and the Shoulds are delivered on time. As a rule of thumb, within any given timeframe, the effort associated with delivering your Must Have's should not exceed 60% of the total effort in all the requirements for that timeframe. No more than a further 20% effort should be allocated to Should Have's, with the remainder in Could Have's. I described in an earlier post how MoSCoW prioritisation works, but how is it exercised on the ever-changing project landscape? For ease of understanding (and my own arithmetic skills), let's assume that you have 100 story points worth of requirements to complete within a given timebox. You do use story points, don't you? Adding up the story points for all the Musts should total no more than 60, and the Shoulds a further 20, right? Okay, so we are merrily developing the solution, when our business ambassador mentions that he's just thought of a new requirement. Okay, this is not too difficult. The process goes like this – Get the team to size the new requirement. Give it a story point estimate relative to all the others in the same timebox. Let's assume it's a 5 point story. Get the business to prioritise it. Assume it's a Should Have In the next timebox planning session, enter this new requirement into the pot of remaining stories to be considered, and get the team to select the stories they should be working on within the upcoming timebox. If that story is selected, it gets developed. If not, it won't. Yet. Easy. Now ask the business which lower-priority story gets sacrificed to make room for the newcomer? We have a fixed project team and a fixed amount of time, so we have to have a fixed amount of work. Adding new work means sacrificing another piece of work of the same size. Getting the business to select which lower-priority requirement gets sacrificed is a good way of ensuring that the business remains engaged and ultimately gets what they want. Change the priority of the selected sacrificial Could Have to a Won't Have for this timebox. Remember the priority only applies for a specific timeframe. It might well be that the story is still a Should Have for the Increment; it will just have to wait for the next timebox. Ah, but what if the new requirement gets raised during an in-flight timebox? What if the Business Ambassador wants this requirement completed in the current timebox? The problem with doing this is that the newcomer needs to be estimated in order to compare it with the other requirements already in progress estimation happens collaboratively, right? Okay, so get the team to spend a minute or two after the daily stand-up to estimate the relative size of the new story. Now get the team to prioritise it and proceed with steps 4 and 5 above – choose the 'sacrificial lamb' and downgrade the priority. There is absolutely no point in continuing to work on something the business doesn't want until later. Of course, if work has already started on it, you may need to choose another one if unpicking the work already done is not a simple matter. But what if you have so many of these new requirements that you don't have any Could Haves left? Start sacrificing the Should Have's of course. The essential principle is that you are always working on the highest priority requirements and this relative prioritisation needs to be a business decision. The trick is to recognise that when you are sacrificing Should Have's from the Increment – i.e. they will not get delivered to Production during the current release – and make the change control a little more formal. Why? Because this means that the business case is potentially threatened. Someone a little more senior should be decided whether it's okay to drop Should Have requirements from a release because it may mean that there is less benefit to be realised or the need to introduce costly manual work-arounds may negatively affect either the costs or benefits. Continue reading
I recently agreed to give a presentation at a project manager's forum meeting. Without knowing the date, I completed the presentation and only then discovered that the meeting was on a day when I was away for a few days. Unable to deliver the presentation in person – one of only two items on the agenda – I asked another attendee if he would mind doing it. When he agreed, I talked him through it over the phone so he would be comfortable with the material and the message I was trying to convey. To my surprise, he then sent an email, with my slide deck attached, to all the attendees in advance of the meeting. Why, I wondered, would anyone do that, especially when it was intended that the material be presented with the audience in the same room? There are two ways in which slide decks are created, depending on how they will be presented. For reading. Because there will be no supporting talk, the slides need to be more detailed, to convey the same information by words alone. Since they don't need to be visible from the back of a room, slides meant to be read at a desk or on a monitor may contain more words of a smaller font. For presentation. Fonts tend to be larger and bolder with greater spacing. Sentences give way to bullet points with very few prepositions. They are meant to be snappy and easily remembered, but rely on the verbal – and body language – component to ensure clarity of understanding. Now, considering that my slides were created with the second purpose in mind, sending the material in advance risks those who bother to read it either not getting the full picture or attending with a head full of questions, having already formed an opinion about the subject. The audience may be cynical or sceptical, in which case the presenter makes his own job very difficult. Alternatively some of the audience may just 'get it' and attend with their minds on other things; or worse, not attend at all. An effective presenter needs the focus of the audience to be on him, not elsewhere. Even distributing the material in printed form takes the audiences attention away from the presenter and onto a different point in the slide deck. If the material comes as a surprise, the presenter can lead the audience through the story outlined on the slides, to most effectively inform or influence, answering questions and concerns as they arise. Continue reading
Back in July 2010, I received an email asking me to comment on a white paper which described "the benefits of running PRINCE2 and DSDM together and to provide a general overview on how to achieve this". To put this in context, I work in an organisation which, like most, has a tradition of waterfall-style project delivery with an intranet-based lifecycle process description, based, I believe, on PMBOK rather than PRINCE2, but those differences are moot for the purposes of this discussion. What I was being asked, in effect, was why can we not fit DSDM Atern into the existing waterfall governance structure we currently have in place? Although my reply has long since been deleted, it went something like this: "It should be borne in mind that the white paper referenced is produced by a consultant – albeit a very experienced and highly respected one – who has a vested interest in widening the appeals of DSDM into potentially lucrative markets like the UK government, for which PRINCE has been the standard method for a number of years. The government, likewise, has invested millions of pounds in PRINCE2 and might be reluctant to let it go completely. There are certainly advantages for an organisation using PRINCE2 to adopt agile practices, and if they are going to do that, I suggest DSDM Atern should be the method of choice. However, there are fundamental differences in the mindset required to get an agile team working effectively that is at odds with the philosophy of PRINCE2. The latter is all about management". Heavy, bureaucratic, overweight management. Agile teams generally view management of any description as a bad thing, but I have blogged previously about that topic elsewhere, promoting lightweight project management as very necessary. I concluded by saying that "I can see no advantage in the combination of DSDM Atern and PRINCE2 that I could in using DSDM Atern in a properly-controlled fashion all by itself". I heard no more about the subject. I was reminded of this email and the white paper earlier today while having a chat with Craig Cockburn who has blogged about this same topic here. As Craig says "…whilst it is possible to combine DSDM and PRINCE2, DSDM Atern by itself is actually enough". I didn't realise it when I wrote my email but I was agreeing with Craig completely. Incidentally, the UK Institute for Government has recently reported on government IT and recommended a more agile approach. It is likely that DSDM will play a large part in that strategy. At least I hope so. Continue reading
Here's a post I wrote back in July 2006. Amazing how little my philosophy has changed since then, despite embracing agile. If you are new to the profession, here's my top 5 'laws' * If you are not busy, you're missing something. * A PM is only as good as the people he has working for him. Treat them that way. * Project Management can be broken down to just two major tasks – risk management and people management. Everything else – planning, tracking, resourcing, budgeting, change management, etc. all fall into one or both of those two categories. Think of everything in terms of what risk it represents to the project or the project team. * You can control the products and activities required by your project, but you cannot control the people. Don't try. * A Manager's job is not to make people work, but to make it possible for them to work (Peopleware – De Marco & Lister). Continue reading
This is not my first blog. I started blogging under a different identity – an anonymous one – back in 2006. It was, like this one, about my working life. But in 2009 I stopped. Just yesterday I wondered why and just a few minutes ago I went back to a few posts I wrote between January and May 2008. Why then? Because those were my first few months at my current company. What made me come and write this post was that those early posts were about our initial adoption of Atern. What struck me about those early days, looking back now, was how much of the agile concepts I grasped straight away. It was like I was born to do this. God, what an awful cliché! But I was also struck by how little I understood of the subtleties of Atern and why some of the details are defined the way they are. That took a bit longer. Tell you what – if you're good boys and girls, I will reproduce some of those posts here rather than linking to them. I might also take you back a little further; there one or two lessons I'd like to remind myself of. Continue reading