– Back to the Agile Practice Guide (all) –

We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance.

The reason we’re looking at these is because as you go along your Agile journey there are many different Agile methods that you’ll come across and that people may be using, or may not be using, or maybe partially using.  And there are also many Auxiliary methods and even scalable methods that you’ll find within Agile where people are calling themselves Agile and using one or some of these methods, and it’s just nice to know what they are, a little bit behind them, how they match up with the core practices of Agile so you can really tell if that team is genuinely Agile or not.

The next one we’re looking at is XP or Extreme Programming.

The Core Agile Framework of XP

XP or extreme programming is a software development method based on frequent cycles. So already we can see a core Agile practice, having frequent cycles or iterations.  XP is known for popularizing a holistic set of twelve primary practices, and these later expanded into other secondary practices as well.  The reason why this has become a core Agile framework is because you’ll see many of the Extreme Programming principles as part of the core Agile practices as well.  For example frequent cycles, sitting together with the whole team, testing first, all of those things that we’ve been through.

Let’s quickly go through them now – from an organizational perspective we’re sitting together, we’re sitting all in the same place so that the communication channels are nice and easy. We can look over our shoulder and say “hey Jane, do you have this information? Because I really need it,” and she can say “You know what, I’ve got it and here it is.”  You don’t have to wait for an email three days later or a week later or maybe that person doesn’t want to speak to you at all and you can’t get that information.  So sitting together as a whole team, the whole team approach where we’ve got the product owner we’ve got the cross-functional team members (the T-shaped, generalizing specialists). These people have a broad range of knowledge and also one deep specialty. Then the facilitator role as well to facilitate those daily stand-ups or daily scrums. We’ve got an informative work space, which as you could imagine is Visual Management with a Kanban board. From a technical perspective we’ve got pair programming, test first programming and incremental design – so we’re designing in increments and features and developing those features and releasing those for our customers.

Pair programming – so we’re sitting with either the product owner as a developer and making sure that everything is being developed in the way that they want, or sitting with another developer to help check the code as we’re going along, basically we’re working as a team in pairs.

We’ve got test-first programming where it’s our test-driven design, where we write the test first and it will fail because no code has been written to support that test. But then we’ll write the code and then the test will pass, obviously because we’ve written the code to support that test. That’s test-driven development.

From a planning perspective we’ve got user stories, weekly cycle, quarterly cycle and slack. And we’ve seen those user stories – those are the things that we’ll put into the product backlog and that’s what will go into our iteration of two to four weeks.

From an integration perspective we’ve got the ten-minute build, continuous integration and testing first, and we’ve looked at continuous integration as part of our core Agile practices where all of the changes will go up into into one environment and then be tested usually on a daily basis to see whether we know that everything is working as it should, even with multiple changes in play.

With our secondary practices, we’ve got real customer involvement, so we’ve got our product owner who represents the customer but we also get real customers involved – people who will genuinely be using this product.

Teams can work at a sustainable pace – so we don’t want to be going in ebbs and flows, we don’t want people to be burning the midnight oil and then having to crash two days later, or maybe disappear altogether. We want people to just have a nice sustainable pace that can go on forever. It doesn’t have to be too much, it doesn’t have to be too little, just has to be sustainable.

Then we’ve got shared code, and collective ownership of code, we’ve got documentation from code and tests and refactoring regularly. So refactoring is just making sure that we’re getting rid of the the non-essential items of code or maybe simplifying that code where necessary, and we can use that on our process as well – we can simplify our process, “refactor” that in a way when we’re planning.

We’ve got root cause analysis on any problems, shrinking teams, pay per use, negotiated scope contract and daily stand-ups, and we’ve seen many of these in our core Agile practices and from an integration point of view a single code base, incremental deployment and daily deployment.

And those are the things you’ll see in XP or Extreme Programming.

– David McLachlan

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck or the Five Minute Lean Book:

View All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable. You can get the whole book on Amazon here and enjoy your own copy.