Tag Archives: agile

The Dream Team Nightmare

Books tell stories to teach us important lessons in a variety of ways. Many ‘howto’ type books tell us what to do in a logical, linear path from beginning to end. Some of these might have quizzes and exercises that help us to learn the materials. Portia Tung’s book The Dream Team Nightmare uses a different device to help us learn ‘howto’ be an agile coach.

Cover of Dream Team Nightmare

Cover of Dream Team Nightmare

The Dream Team Nightmare book  is a ‘make your own adventure’ story so as you follow choices and move around the book. For example, you might find something like this “if you decide to take a walk turn to page .., or if you decide to have lunch with the team turn to page …”, which means you follow your logical path through the book, but in a meandering instead of linear path. Your goal is to make it to the end of the contract with the team and not be fired by the manager.

Instead of ‘learn by telling’ book, this is a ‘learn by seeing and doing’ book. You see what an agile coach does and you decide what our hero does at various times. Sure, you’re still limited by the choices on offer, and you might see other options that might have been, but this is a realistic scenario to show you what being an agile coach is like.
This is highly readable book that will provide you a good read, and leave you thinking about your choices and options long after you put the book down. Go read it and tell your friends about it too.

Simple (non-coding) TDD Game

I did an intro to test driven development (TDD) talk for TechMeetup Aberdeen last night and started with the ‘simple TDD game‘. I modified the game based on comments there, and made a few changes of my own. I used 2×4 Lego bricks as ‘rulers’ to be the ‘testing tool’ as this was easier than finding a large number of actual rulers. I also added the ’round zero’ as suggested to show ‘current state’.

I wanted to try this game as it was the only TDD game I could find that wasn’t also a coding exercise. I wanted a way to introduce TDD to an audience that held a mixture of developers and others. It also let me try the game to see how it might work with a larger group of students by way of introduction to TDD at a later stage.

My modified game ran as follows:

Three one minute rounds with variations:

The ‘dev’ folds the paper where  a fold should be, say 1.5cm, or 3cm in from an edge, or in our case use a 2×4 Lego brick (3cm long), but you could also use paperclips or something else that’s readily available to use as the ‘inspection tool’.

The ‘tester’ measures the fold to see if it meets ‘spec’.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration. Keep track of your score on a piece of paper.

Round 0 – Throw it over the wall simulation

There is no talking

Sit back to back, or maybe at different tables in the room if space allows. We were in a lecture theatre so side by side seemed to work ok. The dev should fold as many as possible and hand them to the tester, who should test as many as possible.

(You could discuss ‘queue’ wastage comments too about ‘stack’ waiting to test, and feedback loop on ‘right/wrong’ during retrospective of round.)

Round 1 – Test After Development (TAD) simulation.

In this round, have the dev make the fold and the tester measure the placement of the fold. If it’s right, then good work! However if it’s not exact, then the paper is given back for a refold. At NO time can the dev person utilise the ruler, this is only to be used by the tester.

Once they ‘team’ get the fold right, the unit of work can be counted as complete.

Round 2 – Test Driven Development (TDD) simulation (almost pair programming)

Allow the dev to utilise the ruler, the ruler in this instance simulates the ‘test’ by having the dev use this the fold should be right first time. The tester can help in whichever way seems suitable.

At the beginning of the round, have the team estimate how many accurately folded pieces of paper they can produce in the 1 minute iteration.

Finish, review the scores, discuss the insights from the game and relax.

We did brief retrospectives after each round to see how many people completed successful and what the ratio of folded/correct was for the teams. We didn’t go into comparisons of team practices, but that would be something to consider for a longer session perhaps.

One team inadvertently tried batching the folds as pieces stuck together, which led to a brief discussion of whether this would be a good idea or not. After pointing out that when it worked, this was fine, but that ultimately you’d be letting through untested pieces as you’d only be sampling the output to some extent and feedback would be delayed. Batch size of one is the preferred process for this game.

Some discussion went on about how the game rounds related to programming, and tied into these questions which brought home the main issue of shortening the feedback loop between coding and finding out if there were errors, or bugs.

1) how many of you work with legacy code? (legacy == untested code from Michael Feather’s definition)

2) how do you know your code works?

3) how do you know the new code you just added didn’t break the old code?

4) when will you find out if something broke? (how long is the feedback loop?)

5) what would happen if you speeded up this feedback loop?

The game ran well with the usual fun and noise you get with a good game as people realise the changes they need to make, and cheers at results become known. The one minute rounds went by very quickly and teams that thought they might fold 25 or more pieces found they only managed 10 or so, of which maybe 3 or 4 were ‘to spec’.

In any case this is a game to try again with a larger class. I also want to find a way to do this with only Lego so that I don’t need to keep cutting/tearing up pieces of paper, which become a chore quite quickly. Still, nice game and maybe it’s fine as it is now.

Thanks to Hurricane Four for the game!

The Agile Classroom

The agile classroom in the university should be a cohesive concept that forms a thread through the student’s degree. As the student learns more in the classroom through a mixture of lessons and exercises, there should also be opportunities to use this knowledge in the wider community of the university and its local community. After graduation the student should be able to find suitable work without too much trouble thanks to the mixed education of  lessons in the classroom as well as applied work in the community. This in turn should encourage more students to apply to study at the same place and form a virtuous circle.

That is the short version of the Agile in the University Classroom talk I presented at ALE2012 in Barcelona on 29 August. Each of these components can be expanded further so that we have a better idea of the student, the courses and degrees on offer, the community and the people involved such as other students and staff.

The students are at different levels of ability, which need to be supported in different ways. These range for beginnings to compentent on a Dreyfus model scale (more specifically), or ‘shu’ and ‘ha’ in the martial arts model of learning. In other words, the students are mostly following the rules for the subject they are studying, and some will start to understand the rules enough to know when they can be broken by the time they graduate. We can help to push them to these limits of their classroom abilities if we can also find ways to bring the student into situations where they can use this understanding developing applications for and with the wider community. This will energize the student when they return to the classroom and provide a better context for deepening future learning.

The courses taken by the student should cover the whole software development process in an agile manner. This should include the four process phases: define, design, develop and deliver stages, and not just focus on the obvious deliver stage where the software is built. Rather, the courses should include service design and design thinking in the define and design stages, as well as continuious integration understanding in the deliver stage. Therefore the student should be able to learn about all of the stages and understand how to work within each of them in an agile manner. Ideally, they should also be able to do this within the community too, so that their understanding is gained in context as part of their degree.

The community offers a number of opportunities for students to gain praxis with their classroom skills. There is athe local community of developers, designers and enterprenuers, who can come together and build up their skills in a mutually supporting fashion through coderetreats, hackday events, and sharing of experiences through workshops and talks. There is also the academic community with its research projects that will need applications developed. There is also the local business community that also needs applications developed. In both of these cases the students should be collaborating together to build applications, and not aiming to undercut the local market for software developers. Where possible the students should be able to attend placements (internships) with software houses to learn how their classroom skills translate into everyday skills at new levels of understanding.

This is the idealised situation of course, and not all of the pieces are in place. Resistance to them can be from a number of directions. These are new ideas that will disrupt old patterns of learning, and change some of the nature of work done by staff too, but also bring in a number of benefits in that their projects should be developed sooner with the help of students practicing their skills. Others will worry that some of these ideas will need some trialing to ensure that the idea is  implemented in a suitable manner, which means that mistakes will be made along the way, and that scares some people, who fear that this will reflect badly on them, and not that it merely means the implementation needs to be improved.

Students will also worry about this approach that sees them working on projects and not saving the project through their ‘hero programmer’ efforts of nightlong coding sessions. They will understand this better when it is seen in context of their work and discussions in the wider community.

An agile classroom at the university is possible and is being developed. It takes a community to build this and a community also benefits from this too.

Reflections on ALE2011

The university aspect

I went to ALE2011 looking for a chance to meet and talk to like-minded practioners, thinking that I would come home with more ideas to use in my teaching. Although I knew it was an unconference and I’d been to a few Scotland BarCamps a few years ago, and found them useful, this was so much more useful for me, as well as for those I met too. That’s why I look forward to next year too.

It probably comes back to the self-selection issue. We all choose to go to ALE2011, knowing that we’d probably need to do a lightning talk for five minutes on a topic we could share with others. This made all of us realise that we could share something, and also learn something from the others.

While I wanted to go and share my understanding of agile and lean at the university, or at least my experience and perception of it, I did wonder how many would turn up for my talk after my talk was accepted. I was happy to see a nice turn out for my view on what universities should be offering for agile and lean in computing/informatics departments, what you can do to improve on the basics, and what those who want to bring the universities into the discussion of agile and lean can do to get this started. Thanks to all of you who came, and for those who offered apologies for not coming (I would’ve gone to one of the others too if I could have). All of this was good.

I also found it even better when it was suggested we do an open space session together on the topic of ALE university to pull together an action plan, and found people came. This was great, some where others who’d not made it to my talk. Then it got better: people talked to me during the breaks about the topic and wanted to know what they could do, and suggested ways to help. This was awesome. Here I was, someone who teaches others how to be practitioners, amongst a group of very capable practitioners, getting asked for help. This was new. This was fun.

And it continues with some of us continuing on the idea of getting more universities involved with the notion of an ALE University day at some point in the future. I’m interested to see where this can go, and what impact we’ll have.

The other parts

ALE2011 only had selected talks in the morning. These were all good and for the 25 minutes we each had, more than enough to cover the topic. Afternoons were filled with lightning talks and then open space discussions with seven or eight of these in parallel for three or four hours until dinner time. Lightning talks are when you get in the queue of people wanting to talk, and when your turn of three minutes comes up, you get on stage and do your talk. Three minutes of fame – and some of these sparked open space talks later which was also neat to see.

The open space sessions were organised by everyone – some 200+ people – saying what they wanted to offer and putting a sheet of paper with the topic on the timetable picking a time which suited them. This was amazing to watch as the forty or fifty slots for the afternoon filled up in a matter of minutes as people said what they wanted to share and learn more about from other people. The power of self-selection by the participants showing that everyone who was there had something to share, as well as something deeper they wanted to gather from others too. This is a very simple, but powerful idea, which should be used more often.

The unexpected joys of meeting people

I knew it would be good to meet people in real life, whom I only knew via twitter, or email and coursework in the case of a software project management student attending. What I didn’t appreciate until I started talking to them all though was how well we already knew each other from the interaction we’d already had through twitter. Sure, you follow some people and have the comment and reply dance now and then, plus maybe some DMs with a smaller circle of people too. However, I found here some of the people I’d possibly interacted with more than I had appreciated. The result was just breathtaking. Here were people I’d shared discussions, asked questions of, and gotten answers too, plus offered some of my own. It was like the old high school friend you’d not seen for ages, but pick up right were you left off, when you meet again. The diffence was that we’d still had those conversations hours, days, or weeks before via twitter and email. This was an unexpected joy from the conference. Now instead of a tweet and a reply later in the day, we could chat during the breaks or over a meal, or a beer. It was great hearing and sharing stories. It was also really nice to be able to just join in any conversation and take part, no matter who was there. It didn’t matter if they were a big name person, or a fellow learner. We were all equal ‘because we share’ as the motto of the conference shows. I look forward to doing it again. Maybe I can even get the whole family there too, as some did for the spouse and kids programme. That would be awesome and they could see what I do.

Lessons to remember

From the talks I attended these are the things I need to remember to do more of, because I’m not doing enough yet:

Reflect on what I’m reading, hearing and doing as part of the reflection cycle. I’ve this blog, so I should use it.

Do more thinking with my hands as part of a team, and find ways to have students do more of this too. The Lego in the office should be used more regularly as I see it.

Integrate more agile and lean practices into the curriculum of my courses, and see if I can’t get others to do the same.

Keep in touch with more people more regularly via Google+ and LinkedIn and not just focus on Twitter. There are lots of useful ways to share ideas and make the work easier by sharing it out, so I should get better at using them.

As someone said, we need to do more practicing of what we ask others to do, so that we can lead by example.

Agile, evo and kanban games

As part of the MSc summer projects preparation I ran a number of workshops and lectures on agile, evo and kanban related topics. These all went well. Some of them were being run for the second time (agile with Lego and the Evo workshop), so they went smoother, while the kanban game was new. I dropped James Shore’s agile customer game and put the kanban game in its place as it seemed more important to run the kanban exercises instead.

The Lego game went much better this year than last. We stayed alert to students trying to pre-build sections and also ran it much better to time. It was good to see that they quickly picked up the details and learned the value of planning which features they were trying to build each iteration instead of just starting to build without planning. See, agile does have planning.

The evo game is based on Ryan Shriver’sMeasurable Value with Agile‘ article, and still needs some work to integrate it better with Tom Gilb’s worksheets on requirements and such like. The ‘game’ is lurking in there and now that I’ve seen a few other software development games, I think I can see how to make this better for the future.

The kanban game was from Tsutomu Yasui, who presented it at Agile 2009. It went real well by the third variation and has probably helped the students manage their own kanban boards on their projects over the summer. The game shows the benefits of applying limits to your work, so starts with a version where you don’t apply limits to the work in progress and then starts adding them in to show how this helps speed development. This worked quite well and I know that I’ll defiantly run it again in the future.

All of these games were run after a lecture/discussion of the topic so they helped to embed the ideas for the students, who could see more than just diagrams, and words about the topic. The game helped show the ideas in practice. I wish we could do this more often with other classes, as this format of lecture, break and then workshop worked real well. It made for an intense week, but worked real well as a prelude to the students working on their group projects.

Solution to fixed price projects

I  found the solution to pricing agile projects. It has been staring me in the face for ages. You see it mentioned by lots of people: Anderson, Gilb, Cohn, Poppendieck, etc. It’s obvious really when you think about it. However, it took Alan Shalloway, Guy Beaver and James Trott to spell out the answer in their latest book. The short answer is: ROI. As Alan et.al, argue in their new book Lean-Agile Software Development: Achieving Enterprise Agility that, assuming you need to work up a RFP where scope, budget, due date and quality are locked, then you can respond and point out how iterative releases will ensure the project stays focused on business needs and enables a faster return on the investment of the project.

With this in place you break up the project into at least two releases, assuming that this is possible (you’re not building an air traffic control system as Allan et al mention), and determine the most business useful features to put into the first release and then get feedback on that while working on the remaining features of the product. If you can break this product development project down into more releases, then their is more possibility of greater feedback and an even earlier return on the investment. Needless to say, you use the usual agile approaches to improve quality, and handle scope.

Using this approach you can make a compelling proposal. First, you can deliver more functionality sooner. This helps to ensure the project achieves it business goals, by ensuring useful feedback earlier from real users. Second, you can provide a faster return on investment for the project, which releases funds back to the firm sooner. This enables the capital to be put to other uses sooner. Third, you may finish the whole project sooner than their planned date because you’re focusing on the needs of the business, and yes, you committed to deliverying all of the scope in the project, but this should happen faster due to your agile and lean approach to the project. This assumes that the scope mentioned in the RFP is still relevant at the end, and hasn’t been changed too much during the life of the project. In any case, you can assume to be able to delivery the completed project early, which opens up new possibilities for both you and the client. They can start another project, they can add more features, whatever.  As for you, your team can move onto a new project or continue with this one depending upon what the client decides.

Agile and Fixed Price Projects

I was meeting with some local developers the other night and one of the topics that came up was how to move from traditional fixed price projects to agile ones. The developer I was chatting with works for a firm that submits tenders to projects, where the clients all expect, and want fixed prices for the project so that they can submit their budget. His experience in trying to move to agile projects was that these are hard to tender because their costs look too high, and then they end up being undercut on price by competitors.

There has to be a way to do this: make this transition so that clients know you can do the work and do the work as required to meet their requirements. However, I’ve not found much on the topic on the interweb. Have I just missed the memo, or is it hidden somewhere? Surely others have gone down this road too, and written about it?

What I did find was a few links to useful papers and experiences. Start with the two pieces (part 1 and part 2) by Pascal Van Cauwenberghe under the ‘reading and books‘ page. Vikrama Dhiman also has a few points on fixed price projects on his blog, but argues the counterpoint to Pascal, so maybe that issue about ‘bidding low’ is up for debate.

My own feeling is that agile and evo teams should be able to make a compelling offer as part of their tender on projects, much as Goldratt discusses in ‘It’s not Luck‘. This needs to be a way to get the point across to those submitting RFTs that your offer will deliver something more useful than the spec provided, in a shorter time, and thus for less money in the long run. Maybe I need to find a firm that wants to pursue this further and we can work on it together. There must be a better way.

EVO: Measurable Value in the Classroom

The other week as part of the summer conversion MSc group project preperations I took the Measurable Value case study by Ryan Shriver and turned it into a working example that the students needed to work through. This exercise worked, but could’ve been better. Ryan also gave me permission to make use of his example as I wanted, so I reused his materials where it seemed appropriate. Thanks Ryan!

Shriver works through a clear voluntary organistion example, and provides the answers along the way, as you do with an article. I decided that the students would need to hunt for their answers amongst some worksheets that I would give them. After looking round I found some similar materials  centered around Impact GiveBack, and some relevant news items that I could reduce to workable data. With this in hand we could then work through Shriver’s six steps of Evo.

The other links that had usable background information were: http://online.wsj.com/article/SB121554292423936539.html http://www.newsweek.com/id/62168 (26 Oct 2007 issue) http://www.slate.com/id/2183542/pagenum/all/#p2 and some made up data about goals for volunteer hours and donations that I extrapolated from the data found elsewhere. This meant that the students had something to look through in their hands, and didn’t need to go hunting on the internet to find information. Hmm, that might be interesting to do as part of an ongoing project perhaps, if each team had to do an extended scenario.

Earlier in the day I’d gone through a reduced slideset of  a talk by Tom Gilb in October 2007 to put Evo into context and explain how it approached software engineering and project management. This seemed to go fine, and followed other discussions about waterfall and agile approaches in general. Therefore the general groundwork was laid we were explaining why Evo is required, and how it is used in conjunction with agile projects.

Working through the six steps that Shriver sets out, and approaching the case study the same way that he did, worked well. I could set up the issue and then point the students to the handouts which they discussed in groups around tables. After ten minutes or so, then I gathered up answers on the blackboard and we discussed the solutions provided for that step. Instead of gathering up solutions verbally, a better approach might be to have the teams submit written solutions, which could then be merged at the front of the classroom, so that no group feels there solution was ignored because another group listed it before them.

The only problem encountered was with creating workable impact estimation tables based on Shriver’s spreadsheets. I showed them his examples and how they could be used. A better job next time would be to prepare his examples a bit further, and clarify how the IET relates to the data from our examples, instead of showing completed ones for his example, which was similar, but not quite the same. Providing partially completed ones would mean that they could then fill in the rest per the data they have for the scenario, instead of reading what’s on the ones Shriver used.

All in all, this worked, and I’ll definately use it again next year after I make the suggestions noted above. Having people work through the scenario themselves gives them a feel for the approach, and how it is applied. Having a reading to take away that uses an example similar to the one they worked through themselves is priceless. So far so good, and the projects now seem to be starting off without too much trouble.

Fun and games with Agile

s part of the training and workshops I organised for the group projects I’m running this summer I decided to see how some of the ‘games’ would work in conveying agile prinicples to the students. I tried James Shores ‘Offing the Off-site Customer‘ and the ‘Lego XP Game‘ last week. Both went reasonably well I think.

On Monday I gave the students an overview of why they’d not be using the waterfall model for software development, and why we’d go for incremental and iterative development processes instead. In particular I explained why small we’d want to push decisions to as late as possible because of the cone of uncertainty, and therefore a user story on a post-it note would suffice to capture the essence of the need at the start, and you’d end up getting more details in a chat with the person later when you knew more about the product being developed. I also pointed out that waterfall assumes the product is being manufactured, when in fact, as agile assumes, software development is really, as Clark Ching points out nicely in Rolling Rocks Downhill, that it is product development: what is the best way to make this ‘new’ product or service? Software development is an exploration, and therefore change is the normal state of affairs, as nobody can know all of the requirements up front.

On Tuesday we looked at requirements gathering and user stories. This went well. We also used Shore’s game to highlight the relationship between the customer and the developer. In the first run of the game, where the developer and the customer are divided and the analyst conveys the information, some students started writing down descriptions of the diagram that was ‘the product’, and others only laterly, after suggestions, started going back and forth desciribing what was needed.

In the second version, when the developer can speak to the customer and the analyst at the same table, then this went much better and a few students even picked up the idea of developing ‘tools’ to establish right-angles and function as ‘rulers’. Very nice work by them.

On Wednesday we looked at estimating and planning following the ideas of Mike Cohn. This went well, and we followed it up with the Lego XP Game. This was delivered smoothly, and the students soon learned not to mess with the lego outside of the ‘build’ time, as my assistant and I had to destroy artifacts being built in the estimating and planning stages. Our explaination was that ‘oops, the customer didn’t like that version. A shame you wasted your time building something no one asked you for.’

The game follows a clear ‘estimate, plan, build, retrrospective’ phases and with the help of an online stopwatch worked well. In the second, and especially the third iteration of the project, the students knew what they were doing, and focused on the estimating and planning more appropriately.

We had seven teams of four, as we didn’t have enough lego for nine teams of three – the box of lego that would hold four/five? reams of paper was just enough. The more lego you have the more interesting and easier the tasks are to complete for the teams.

Using both games to reinforce the ideas covered in the lecture worked well I think, and I’ll run them again when we cover these topics again. It broke up the day well, so that it wasn’t just lectures and practicals, but also some relevant experience ‘doing’ what is needed so that the students understand ‘why’ the different steps are necessary. Both games were full of noise and excitement and did a good job of representing the ideas and processes of agile methods. If you’ve not tried them, then you should. You’ll find links to others if you google ‘agile games‘, or head to agile fun.

Agile+Evo and Student Perceptions

As part of a module on the MSc Software Project Management programme I had my students write an essay comparing a work breakdown structure for the iteration of a project and the approach taken for ‘business value delivery’ described by Ryan Shriver in his Measurable Value with Agile article. This produced some interesting results amongst the students.

I had eight essays to read from students, who all work in the software industry. Some work with traditional software development processes, and others follow more agile and TOC approaches, and everything in between.

Of the eight, three thought it was a good approach, which they thought would work well, three had some criticism of the approach, and could see it being applicable in some places, while two were generally against the ideas put forward.

The gist of the arguments against and ‘sometimes’ seemed to be down to two aspects. There were some who had different interpretations of the text, which means that I need to lay out this approach more clearly next time around, so that it’s better understood. Others had a difference in opinion about how the ‘value’ of a solution should be measured. Some felt that you can’t measure the knowledge gained in developing a solution, for example, while others thought that this approach doesn’t take full stock of the margin on some solutions. Again, this looks like I need to lay out the importance of cashflow, and the difference between througput and cost based approaches.

As the course has gone over some of Tom Gilb’s evolutionary project management (evo) ideas before this, I was a little surprised that more weren’t supportive of the ideas. I suspect part of the issue is that I need to take more time laying the ideas out more clearly, which I’ll do when I re-write the course text. Similarly, I’ll also need to lay out Eliyahu Goldratt’s Theory of Constraints more fully. I just finished re-reading them and can now appreciate where they fit into the coursework more clearly. It’s also quite interesting how some parts of TOC overlap with EVO as both are evidence based approaches to solutions with results.

All in all though, I think this exercise will get used again next year, or maybe something similar if Ryan, or someone else comes up with a better ‘step-by-step’ guide.