Tag Archives: evo

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.

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.

Agile + Evo Process for Group Projects Outlined

This is a work in progress. As I’ll be gone for a break I needed to coalesce what I could into some form of document to gather my thoughts on preparing materials for students about agile and evo. The result is this group project page. This page pulls together some of the main ideas for what should be covered by the students as they move to working on real projects this coming summer. 

The next step is to work out the precise details of what I’ll do in each session when I come back, and then develop a viable timetable for a week of delivering a series of talks and workshops on each of the steps. All of this will kick off in May/June after exams so there’s still plenty of time to sort out the details.

In any case, for now I can leave it and have a break. I can also now get into discussions about all of this with colleagues and others, who’ve said they will help. So I’ll wait until I get some feedback from people – so please leave comments below, or email me.

Agile industrial experience for students

Students, especially the MSc students, are always wanting to have industry related projects. One way to do this is to get industry to come to us for software projects. This will not happen overnight however. I’m sure the other universities who’ve done this also started small. Some sound impressive, and are relevance to what we might do. Bowling Green State University in Ohio has an Agile Software Factory, which provides a number of ways for students to participate. New Mexico Highland University also had a similar type of programme too. Closer to home, Kent has the Kent IT Clinic, which uses students to provide light services to local SMEs.

So we can kickstart our efforts in this direction, as noted previously, by going to a local organisation for possible partners. This should work if we can align the possible projects within some basic constraints of projects.

The new student experience should come through developing real applications for local organisations as part of their group projects. The local organisation benefits from having a real application developed for which they’ve previously identified a need and the students gain experience working with real clients as part of a real software development team.

At the moment this is at a trial stage and some pilot projects need to be found for development over the coming summer of 2009. The potential projects should have a few specific characteristics:

  •  Achievable over a twelve to fifteen week period with a workable product at the end, which the organisation can use.
  •  A client whom the students can liaise with on a weekly basis, and whom they can email or phone as required in order to answer questions about the product.
  •  An application that is needed with suitable interaction to meet the needs of a group project. This could be a desktop application, or web application used by staff to fill in forms, or to streamline other business workflow. An ecommerce application would also be suitable.

The project will demand consistent regular input from the client, so that they can help guide the project direction, and so that the direction can be checked and corrected as required. It also means the students will not be stuck waiting for input before they implement a feature of the application.

All projects should follow an agile plus evo approach building upon Ryan Shriver’s approach. This means that they will be done iteratively and incrementally with suitable measurable outputs as to how well each component, will meet the desired business goal of the project. This also means the project will demand consistent regular input from the client, and that there will be a number of points at which the project direction can be checked and corrected as required.

The students who will be doing this pilot come from two different programmes. Neither of them have studied agile or evo before. One group did a typical software engineering and UML course last autumn. The other group has not done this module yet, and will do it later. This is not ideal, but you do what you can.

These students will need a preparation period to learn the processes they need to successfully deliver the product to the clients, and they will also need to learn the reasons for the processes they are learning. If they don’t know the ‘why’ of what they are doing, then they will not apply the ‘how’ they are being asked to complete.

The students need to learn the ‘what’ of agile and evo so that they understand what the life cycle is they are using for their projects. Part of the ‘what’ is also the ‘why’ of using agile and evo compared to the traditional waterfall or spiral life cycles of software development. There are a number of resources available, which cover these aspects.

More pressing is the issue of the students learning the ‘how’ of agile and evo. They need to know and understand the daily practice of agile and evo so that it is successfully implemented to provide a successful (usable) business product for the customer at the end of the project. While there are a number of resources available describing these practices, it would also be useful to tie these in with a series of workshops so that the students can learn the processes before applying them to a real project.

In order for this industrial experience to be successful in the long run more people will be needed to manage the teams and guide them. We will need staff to also participate in the workshops so that they too can help guide the student groups on their projects in a suitable manner.

The main goal of this pilot period is to uncover any issues, which need to be resolved before the scheme can be scaled up to include more organisations, and more student groups. Over time this should become a regular service available to local organisations. In order for this to happen, however a trial project or two is needed to establish its feasibility.