Feeds:
Posts
Comments

Archive for the ‘Book Reviews’ Category

Reviewers required!

 

I am currently in progress of writing my first Agile book. It is basically a beginners Agile book targeted outside of the software development industry with a major twist.

 

If you would like to participate as a reviewer can you please contact me via twitter with an @AgileRenee mention and then I will send you a direct message to get your email address (if I am not already following you, otherwise just DM me). Alternatively you can email me at renee@theagilerevolution.com

 

 

 

Read Full Post »

When I mentioned to some community friends that I was going to be reading Steve Denning’s Radical Management book a number of them looked at me as if I had contracted some form of virus. “Why would you read a dumbed down book on Scrum?” they said.

The answer for me was simple -

  1. Agile, I feel, isn’t an easy concept for Managers to get. I wanted to check the three prominent books on the market that are there to help Managers become Agile in order to see which one I would recommend if I ever had a manager (which admittedly to date I haven’t) one of them asked me for a recommendation.
  2. Because I do feel that it is hard for Managers to get Agile I wanted to see if there were any hints to what I could do differently or on what practices are relevant for Managers.
  3. I really like Steve Denning’s HBR articles. He has a beautiful writing style which I can appreciate for its simplicity and purpose.

Within this book review I won’t be comparing this book to the other two (although I might do then when I review those), instead I want to focus on my thoughts as I read the book.

Firstly, focusing on my third point above I was not disappointed. For the most part I did continue to enjoy Steve’s writing style in this book. Most pages I felt engaged in and whilst the pages didn’t all fly by, certainly up to the end of Chapter 9 they did (from there it does drag on a little).

Secondly, for a manager that has absolutely zero understanding of Agile and has focused for most of their management tenure on traditional command and control methods, either intentionally or not, I feel that this is an excellent book… to start them on the mental journey.

Which brings me into my third point. It tries to give a practical angle of applying it but I couldn’t in all honesty give this book to a Manager and expect them to be able to do the practices effectively. In fact, in a number of instances there is no detail on how to do a practice. So what this book does really well is get Managers to begin to question what they do and how they do it, less so actually enact change. This could be perceived as quite a concern for many but I don’t think it is that big of a deal – the difficulty is in the mindset change and this book does address well why you would want to shift from being a traditional manager to a radical manager. Additionally the book is riddled with references so if you did read this book and wanted to find more than there are a huge number of useful references at the back.

Now for the negative bits (which I don’t feel outweigh the positive):

  1. Some of the examples are poor – they don’t get the message across or they are weak links to the lesson. Steve is a good storyteller, just a few of the stories are duds. The first one in Chapter 10 is an example of a dud, as is the communicating example further in the same chapter. The roles in Chapter 1 also felt disconnected.
  2. The focus is strongly on Scrum. There is little content on Lean and only a sentence or two on Kanban. It would have been nice to have a broader view of being radical aside from Jeff Sutherland’s perspective. I was aware of this prior to reading the book so maybe I was a little more conscious of it than most readers would be. That said, I actually find that non Iterative Agile is an easier concept for Managers to understand.
  3. Iterations. I’m left with a feeling that Steve doesn’t understand what an Iteration is. It seemed to hint more towards an increment rather than an iteration. The examples that he gives on iterations are poor and for a fundamental principle I think it could have been articulated further.
  4. There are some occasional inaccuracies in advice (in my humble opinion) – like the concept that Value Stream Maps would find the phantom traffic jam problem and what defines “divergence” when using Planning Poker.

So it might be early days to know what book to give to a Manager to learn Agile (even if this was not the intent of this book and it’s intent was to be wider in focus), but overall I would give it a 7/10.

Read Full Post »

I had a considerable amount of trepidation when reading this book by W. Chan Kim and Renée Mauborgne. The title itself is ellusive and doesn’t lead the reader to understand the value that it might have for them. The subline is a bit more useful “How to Create Uncontested Market Space to Make the Competition Irrelevant”. A better byline would have been “Major differentiation through innovation”. You see, you will never make the market uncontested permanently. In today’s day and age competition is quick to catch up, maybe that wasn’t the case 7 years ago when this book was initially written.

I put what I had heard of this book aside and read it. Surprisingly for me, I enjoyed most of it. The first four chapters are what I would consider a must read for any manager, leader or product owner. Why? Because it fills a niche where there is a hole – how to create a differentiating and innovative business strategy for your products. It won’t guarantee that your strategy works. It won’t really help you execute your strategy either, but it is a sensible thought process for where strategic ideas could be lurking.

When I had finished reading Lean Startups for the first time my immediate thought after “this sounds like a great way to execute an idea” was “what idea should I execute?” This book gives you the tools to be able to seek such an idea within yourself. Blue Ocean Strategy is the Yin to Lean Startup’s Yang. Similar, but different. Each valuable, but together a powder keg.

So what is it exactly? Well despite what the authors will tell you, it is a strategy set of practices based upon a theory presented by the authors. The theory they have surmised after analysing numerous companies is that the only thing that makes a company successful is major differentiation through innovation (my words not theirs). All too often organisations spend an inordinate amount of time and money on catching up with other competitors or trying the win customers from the same pool. Blue Oceans (or as I like to call it innovative marketspaces) are about finding a new set of customers by differentiating in the market at a more macro rather than micro layer.

The book sets this up through a huge number of examples that clearly present their case. One of the key tools they use is a simple graph that anyone can use to describe their product and their product differentiating characteristics. Below is an generic example of such a graph. 

It should come as no surprise that Kim and Mauborgne are recommending finding out as much about your customer is imperative. But also that you should find out about all those people that are not your customers and why. By asking such questions you may gain insight and be able to differentiate to create a new customer segment. Their key suggestions for identifying innovative differentiation are:

  1. Identify cross industry opportunities
  2. Identify intra segment/industry opportunities
  3. Identify non familiar buyer potential
  4. Identify complimentary packaging opportunities
  5. Identify emotional appeal opportunities (Buyology does a better and more accurate job of describing how to do this)
  6. Exploit trends

Sounds sensible right? But real insight generally is sensible like this and they give excellent examples throughout to back it up. Most of the examples succeeded not because they used this strategy, and it should be noted that they have given no proof to their work nor were they able to recognise the success rate of innovation.

It made me think about the companies that I have worked for and the competitors that grabbed some of the marketshare. Certainly they found a characteristic, focussed on it and were rewarded. I could see some validation behind this.

Then I was curious about organisations that had actually used this and whether they have garnered success. Nintendo is known to be using it – Wii and 3DS were born and arguably they are having success. What is interesting is that as soon as a company creates differentiating innovations others will try and catch up – just look at Connect as an example. Another described project is the creation of the F-35 fighter jet. This jet was meant to be packaging intra segment opportunity – a navy, marine and airforce plane in one. The product characteristic graph for it is interesting but if you have a look at the project which is now eight years overdue and with a price tag of $1 trillion dollars you have to wonder whether it was worth it. Interestingly constant change of requirements has been labelled the cause for the blow out. So maybe the product charactistics were a too simplistic approach to the strategic problem?

But it did make me think about how this might apply to Agile. A graph could easily be made to demonstrate the differences between Agile and Waterfall. Similarly one for Scrum and Kanban. One can be created to define the opportunity that exists in the market. I have seen one done for managers and leaders – of what their current characteristics are versus what the strategy was to move them to it. It made me consider the Rightshifting proposition and the characteristics of the Analytic versus Synergistic mindset. 

This is a simplistic version of it, and no doubt I will have some (all?) elements wrong (read the 10% as low focus on and 90% as high focus on). Where can this graph be improved/corrected? What sort of things can we consider from a strategic perspective?

Lastly, whilst I do believe there is value in reading the book you should open yourself up to other thoughts in the community. The Blue Ocean Strategy has had many scathing reviews of it. Many of the points in the less than positive reviews I do feel are valid. Personally it is just another really simple tool that you can add to your toolbox. You won’t use it everyday, but one day you might need to take this tool out.

Read Full Post »

Buyology (not Biology)

Recommended by Bob Marshall in a few tweets I took Martin Lindstrom’s second book on marketing with me to Austria to read predominantly because it was the most lightweight book in my backlog at 218 pages. In retrospect this was probably a bad idea – mostly because for one the hyped up quotes on the back of the book such as Newsweek’s “A page-turner” was very true. I couldn’t put this book down I found it that engaging and interesting. Read over just two nights, its stories were entertaining, informative and eye opening.

I have no understanding of marketing (so perhaps Lindstrom’s first book Brand Sense would be good for me to read) but I found this book incredibly approachable. It laid the foundation of common marketers and the importance of brand creation and recognition. Then it got into the interesting stuff – the fact that for several decades marketers have had it wrong on a number of fronts. Lindstrom makes extensive use of f MRI and SSTs to get into the brains of us and find out what really drives us to buy or not. Anti-smoking marketing is mythbusted along with interesting stories on the powerhouses of Coke, Pepsi and Nokia.

The parallels between what value people perceive marketing has verses reality and how such similar stories are heard of Agile was often on my mind whilst reading this book. Some in the software industry propose that Agile is pseudoscience that isn’t backed up by fact. The truth is – some are and some aren’t and in some ways we need to get better at measuring what is working or not. I do believe that Agile works but I am not convinced of which elements do versus don’t. I still feel some Agile teams spend too much time in upfront planning. I still feel that empowerment seems to only go so far and that timeboxing to avoid interruptions only works in some environments. But these are feelings that aren’t backed up.

The most interesting chapter was one title “I say a little prayer”. In this chapter Lindstrom compared marketing with the ten pillars of religion – belonging, a clear vision, power over enemies, sensory appeal, storytelling, grandeur, evangelism, symbols, mystery and rituals. Whilst Lindstrom was explaining how marketing similarly had the same foundations I again could see the parallels with Agile.

In jest many (including myself) have referred to Agile as a religion. But here was a clear comparison model and that scared me a little.

Belonging

It is easy to see how belonging fits into agile. We create teams that work together to share a similar mission. Additionally we also have a few communities that we can belong to in a wider group.

Clear vision

The whole point of release planning, creating a backlog, sharing our understanding of the work and how big it is enables the creation of a clear vision. We want to work in an adaptive way and we know that things can change but having a big picture view is also important – just don’t spend too much time on it.

Power over enemies

Waterfall vs Agile debates anyone? 281 comments in a week for this HBR Waterfall v Agile debate shows that there is still a war on. Even religions have factional wars to differentiate themselves – sounds like internal Scrum vs Kanban wars too doesn’t it? Taking another’s rituals and terms and using them as your own also has parallels in the Agile world.

Sensory appeal

This is one of the key benefits of using Agile over other approaches. Post-it notes and system cards overload our visual sensors along with many other information radiators. Business environments generally discourage the touching elements between people, but there is tactile touching of cards on the wall. Communication is heavily used utilising our speech and listening skills. Even our sixth sense is used to estimate cards. The only sensor not used is smell… I smell an Agile opportunity!

Storytelling

I don’t really have to explain this one do I? User stories, user story maps, focussing questions, empathy maps, personas…

Grandeur

Saying a story wall is grandiose might be a bit of a stretch. Agile conferences can certainly be grandiose. Oh well, failed on this one… next?

Evangelism

This is one trait that has been attributed to many an Agile Coach. Do we as a community appear to reach out and secure new acolytes? I fear this is the key reason many associate Agile with religious zealotry.

Symbols

Unless you count Japanese characters of Kaizen and Kanban as symbols Agile doesn’t have a strong focus on iconic symbology. That said, there are a lot of terms that are specific to the Agile community (and branch communities) that to outsiders could have the same associations and intent behind symbology – stories, product owner, scrum master, MoSCoW, poker planning… the list is extensive.

Mystery

I like to think of this as the science vs people debate. Which Agile practices and methods work? Why do they work? What about them doesn’t work? But there is mystery in a different way – mystery in that requirements are to some extent unknown until we have had a conversation, mystery in that what we might deliver in the next month doesn’t match a current plan (adaptive change), mystery in each and every day when we have a Stand-up and we find out what is really happening inside of our system.

Rituals

Even Scrum labels the commonly recurring activities such as Iteration Planning, Daily Stand-ups, Retrospectives, etc as rituals. Add in some wine, bread and absolution and we might just have a religion on hand.

 

Whether you can see the parallels or not, Buyology is a damn good book and I would highly recommend it to anyone. Now, let me find a SST and a stand-up and get started measuring.

Read Full Post »

Game storming book review

Gamestorming, a playbook for innovators, rulebreakers and changemakers by Dave Gray, Sunni Brown and James Macanufo is a great composition of a number of games and techniques out there to reach collaborative and innovative outcomes; well worthy of a read for all Agile coaches.

The form, for the most part of the book, describes the game, the objective, number of players, duration of play, rules, the strategy for facilitating it and kudos to the originator of the game.

It wasn’t that every page for me was a gem, in fact there were probably only a handful of things that I felt I didn’t already know that I could take away and apply on a situational basis. But a handful of things – is a handful more than I had and for me that is still saying something. So lets take a look at the concepts and ideas that made me think:

  • Page 21: Every time I group a set of like themed post-it notes on a wall it actually has a term – ‘affinity mapping’, go figure.
  • Page 39: The airplane metaphor. This reminded me somewhat of the sailboat retrospective technique. The back of the plan is ‘where we come from’, the port holes ‘who do we deliver value to’, the propellers ‘what gives us the power’, the cockpit ‘how do we steer’ and the horizon or front of the plane is ‘where are we going’.
  • Page 65: Empathy map. I actually just appreciated being reminded about this fantastic idea from XPlane. Furthermore I had the fun opportunity to put it into action today which for the most part I felt worked well for the workshop I was in. Looking at the Anti-Problem (on page 80) made me wonder if these two techniques could be effectively applied to demonstrate a customer view/perspective that you want to avoid.
  • Page 113: Pie chart agendas. I hate writing agendas with a passion (the ultimate waste – documentation of a future waste event), but the option to demonstrate in a visual format how much time is being spent on particular activities is a creative approach that might have me doing them with a little more motivation. The full circle of the pie is the total time of the meeting, you basically slice it up into pie pieces of the time proportionately you will be taking for each topic.
  • Page 131: Trading card avatars. Used as an icebreaker this game has the added boon of also generating avatars for the story wall. Basically each person creates their own trading card with a hand drawn picture of themselves, their nickname and  little known facts.
  • Page 165: The Elevator Pitch. Not a new concept to me but a nice format structure – “For (target customer), who has (customer need), (product name) is a (market category) that (one key benefit). Unlike (competition), the product (unique differentiator).”

If you are new to facilitating, Agile coaching or Scrum Master then I would definitely recommend taking a look at this book.

Read Full Post »

It was with some trepidation that I took at look at Seth Godin’s Tribes book. This was primarily due to mixed reports from friends whom had read it. It was so mixed that it  was pretty evenly split down the middle 50% loved it, 50% hated it. Those that didn’t rate it felt that it was overly repetitive.

My immediate thoughts – I LOVED IT! This is probably saying something seeming how cynical or pessimistic I can be about books, blogs, presentations, etc. Without a doubt I would recommend this to others for a read; it is nice and short, about 150 pages and half the size of a normal book. I wouldn’t say it’s insights are anything new for me, but there was a lot of strong re-affirmations to how I feel on a number of subjects. The biggest thing for me about this book was that I felt motivated as a result of it, although my passions are already quite strong, after this book they felt on fire.

Here is my key summary of the book:

  1. Heretics, innovators, revolutionists. Whatever you want to call them it is about not settling for mediocrity and instead striving forward towards an area that you are passionate about.
  2. Those that inspire others with their passion become leaders.
  3. Do something! Take control of your life and join or lead a tribe now.
  4. Sheepwalking is a beautiful term for those who are just following the pack and not asking questions. It’s almost as bad as sleepwalking through our working lives.
  5. Seth Godin’s movement is to make movements. Eat more prunes.
After reading this book and talking to colleagues about it I remarked how I had always felt comfortable with the revolutionist tag but was now on my way being comfortable with the heretic tag. My colleague’s response – ‘You aren’t a heretic, you are a heresiarch.’ I would probably rank the likes of Alistair Cockburn, Jeff Sutherland, Martin Fowler, etc with that tag rather than myself as they started the revolution. For me, it is about evolving the revolution to the next phase.
Some key quotes and thoughts on them:
Some tribes are stuck. They embrace the status quo and drown out any tribe member who dares to question authority and the accepted order.

Is Agile stuck? Are the heresiarch’s beyond reproach and questioning?

Everyone’s a leader.

Hmm we aren’t there yet – but everyone should be a leader of themselves. Do something you are passionate about!

Leadership is about creating change that you believe in. Leaders have followers, managers have employees.

Nice!

Organisations don’t have to be factories, not anymore. Factories are easy to outsource.

This is where our real value add is. As work gets continually outsourced we need to be innovative as thought leaders to continue to preserve our way of life.

When a CEO takes the spoils of royalty and starts acting like a selfish monarch, he’s no longer leading. He’s taking.

Don’t get me started on this one. I just want to re-affirm that I believe this strongly.

It’s easy to underestimate how difficult it is for someone to become curious. For seven, ten, or even fifteen years of school, you are required to not be curious. Over and over and over again, the curious are punished.

Wow. I say this regularly and it always felt like no one understood this. Maybe Seth is a secret twin? It’s not just the curious, we are molded to do exactly as we are told by parents and teachers, to comply. Why is it so hard to say ‘no’ to your boss for that new piece of work when you are already 150% overloaded – it is because of many years of conditioning as a child to not say no to a perceived position of power?

Heretics don’t settle. Managers who are stuck, who compromise to keep things quiet, who battle the bureaucracy every day – they’re the ones who settle.

Around about this time in the book I began to wonder – Do you have time to be a heretic? It felt like the book was pushing everyone in the direction of getting their word out. That could be internally within the organisation or wider on the internet. The internet approach would take time out of your busy personal life. If it is something you can spare and have the passion for it will be an easy choice. For those focussed on many things, juggling many activities including a family this will be harder. You might have to drop a hobby, but then again, your hobby should be an area of your key passion.

The new leverage available to everyone means that the status quo is more threatened than ever, and each employee now has the responsibility to change the rules before someone else does.

Innovate quickly, fail quickly, adapt quickly.

Faith is the unstated component in the work of a leader and is underrated.

The book makes a point that religion = rules and  faith = culture. Your tribe is your religion. Your faith is in your tribe’s values. I have heard Agile evangelists often called ‘The Agile Jihad”. It made me think about the training we provide and how from an outsider’s perspective it does look like an attempt to ‘convert’ others to our religion. For my two cents my religion isn’t necessarily Agile, it is a religion of embracing new ideas and change, of keeping people first.

It’s okay to abandon the big, established, stuck tribe. It’s okay to say to them, “You’re not going where I need to go, and there’s no way I’m going to persuade all of you to follow me.”

And lastly,

If you hear my idea but don’t believe it, that’s not your fault; its mine.

If you see my new product but don’t buy it, that’s my failure, not yours.

If you attend my presentation and you’re bored, that’s my fault too.

If no one cares, then you have no tribe. If you don’t care – really and deeply care – then you can’t possibly lead.

Read Full Post »

This one is for Mhano. Book 2 of 11 for the PMI Agile PM certification syllabus - Agile Project Management with Scrum by Ken Schwarber, 2004.

Okay well firstly it is obviously about Scrum and doesn’t cover anything XP or ‘A’gile related. Given that it is getting a bit on in age I thought there would be more that I would disagree on but surprisingly little has changed over time.

If you want to know Scrum it is a good start, but really there isn’t a lot of depth to this book with a majority of the book focused on case studies. Ken admits that that is his focus at the start and he leaves the first chapter and first appendix as the process and general rules of Scrum. He wanted the rest of the book to be more about the ‘feel’ of Scrum but really it reads like a number of notable failure modes or Scrum Master correction tips. Whilst some of this information is useful it really is the tip of the iceberg and there is not enough coverage of other information to recommend this for anything past a novice level of information.

Comparing it to the two day Certified Scrum Master (CSM) course, it is probably the same coverage.

Ken openly discusses in the first chapter that Scrum is an empirical process control, meaning software development is hard and consequently the only process we can rely on is visibility, inspection and adaption and then goes on to explain how Scrum fulfills this. It is a valid value proposition and well explained.

The book then goes through the key Scrum roles and a number of other Scrum terms as you proceed through the case studies. As always my main beef is not directly related to this book, but at Scrum itself. I loathe the term Product Owner. I feel it is a poor reflection of a commercial world outside of small software development houses. Rarely do you have someone who is the Project Sponsor, Business Owner and Business Representative in this one role. Merging all three is confusing and not a reflection of standard governance and delegated levels of authority.

Similarly I hate the term Scrum Master, but I also hate what it has done to jumble up the meaning of Agile Coach. They are different, but similar and I don’t know if it is doing us justice having this role. More importantly I fear that the role of Scrum Master is counter-intuitive to the generation of a self empowered managing team.

Nattering on, I also hate the term ‘Product’, specifically when associated with the backlog. This primarily is because it limits the application of Scrum to anything to do with ‘Products’. You can apply Agile and Scrum through so many things other than software development and so the term product for me just doesn’t sit right. Call it a work backlog and be done with it.

Maybe I slept in the CSM class but I can’t remember the strong enforcement of scrums having to be 30 calendar days. I’ve always just used standard lengths of iterations to what suits the circumstances. 30 days seems a little prescriptive. Burn down charts have also advanced away from what is described in the book with Burn Downs generally representing hours and points being burnt inside of the iteration and the release burn done going upwards against scope.

Similar to my major gripe with the CSM course there is no coverage of the art of generating the backlog in the first place, it magically assumes a fairly burped one out. This is an art. It is not simple and for it never to be covered anywhere is just sad. There is a very small reference to doing this in one day…. yeah. I am dubious of the quality of a one day created backlog for a greenfields project. There is definitely something in Feature Driven Development’s domain modelling that is missing in this picture.

The rules at the back are a little outdated but for the most part have their heart in the right place.

Read Full Post »

Over the last few months I have pondered going for PMI’s Agile PM certification. Unsure of how dedicated to this cause I might be, I decided to at least start reading the eleven books on the syllabus and see how I felt after reading one.

The first one was “The Art of Agile Development” by James Shore and Shame Warden 2008. Unlike most of the other books this is one that I have not read and I wondered whether I would get much out of it other than an increase of my own Agile Data Dictionary (otherwise known as the mysterious wheel of terms that mean the same thing but are subtly different).

Because I am a ‘glass is at 50% capacity’ sort of person let me start off with a positive (yes I know that doesn’t make sense, but I just watched House and eww I’m still trying to mentally get over it). If you are a beginner to agile (note the little a) then this is really a good book to start with. It doesn’t cover everything, but it doesn’t say it tries to either. I would recommend this book.

The book is primarily focussed on XP practices. Now keep in mind that XP is at its heart exactly that – practices. This book takes the position that XP has evolved away from just the technical software development practices and is beginning to broaden its focus, albeit in this book it keeps calling all the other stuff practices too. This is where the big ‘A’ comes in. I like to think of Agile as not just either XP vs Scrum vs Crystal vs Kanban; I think Agile is taking what works out of all of them and applying it appropriately.

This book tries to take some of that ‘A’gile thinking and includes topics such as Energized Work, Trust, Slack, etc. This is definitely a good thing as I always found it odd that XP was so incredibly technical practice focussed, but you need to beware that a lot of the content that is being covered actually exists elsewhere in the land of Agile.

From a negative perspective the Practices by Phase table on page 21 made me want to shut the book straight away. It was there to ease the waterfall people but the association of practices to phases are incredibly wrong and most of the practices exist throughout the life of the project. The practices cross reference on pages 26-27 is equally cringe worthy with Scrum apparently the only other model for agile implementation.

Other notable thoughts as I read through:

  • Data dictionary #1 Energized work = Sustainable Pace
  • Data dictionary #2 Informative workspace = Information Radiators/Big Visual Charts
  • Root cause analysis… surely this is more of a generically known term and not an XP practice.
  • Trust… as a practice? I guess. It is a value to be upheld. Is upholding a value a practice?
  • Data dictionary #3 Sit Together = Co-location. Really the word co-location wasn’t used once?
  • Real Customer Involvement… apparently only at Analysis phase. Please can’t we have real customer involvement throughout?
  • Ubiquitous language… seriously don’t get me started on this one. Who in their right mind uses a term like ‘Ubiquitous’ to describe what should have been ‘Simple’ or ‘Audience specific’. This goes along with the weird term ‘Etude’ used throughout.
  • Data dictionary #4 Demo = Showcase
  • Reporting… as a practice? I can see Burn Up and Down as a practice but a generic heading of Reporting is a bit of a stretch. The help box “Only produce reports that are strictly necessary” should have taken up a whole page and that could have covered it better. Nothing in here about a Car Park Diagram, but then again that’s an FDD practice and this is an XP book guising as an Agile book.
  • Data dictionary #5 Done done = Definition of done. I am probably more familiar with the former than later anyway.
  • 10 minute build… love it! I remember having a problem with this one once so I was really happy to see this.
  • Documentation… again not really a practice and dare I really have to go back to the manifesto on this one. Thankfully iPhones have moved on since 2008 and most of us deal with documentation these days as simple snapshots uploaded onto a central project repository.
  • Release plan… it was nice to see the information on this subject represented how it was. One of my pet peeves in the idea that at the start of a project all the work is going to be scheduled into a detailed, Gantt chart like release plan. This section didn’t do this and really focussed more on the adaptive planning of the work.
  • Data dictionary #6 Planning Game = Estimation and Prioritisation. How I have always hated the term Planning Game. Nothing was mentioned here about MoSCoW or Planning Poker (or anywhere else in the book).
  • Risk Management… apparently only gets done in planning (thought the text later says otherwise).
  • Data dictionary #6 Performance optimization = ensuring you have the means to cover off the performance non functional requirements. Again, not really a practice.
  • Exploratory testing… old school software development stuff, not something that XP should claim fame to (not that the author is notably).
  • Practices by Role table is very poor, ignore it; or at least definately ignore the overloaded ‘Coach’ column.
  • Maturity Assessment pgs 63-66 might be useful /shrug
  • Not a fan of the concept of Step 3 in retrospectives “Mute Mapping” whereby you quietly group like themes together. Why wouldn’t you do it as you are facilitating?
  • Not a fan of only fixing one thing and only one thing in retrospectives. Why have this charade of listing everything that isn’t working and needs changing. Now I am not saying fix everything, but surely more than one thing can be fixed! Maybe this is why people have such a rough time following through on actions? Nah, it’s because actions aren’t written as stories and scheduled into the iteration and hence followed up.
  • Version control… old school software development stuff, not something that XP should claim. I was impressed however that they did talk about branching and advised against it – Yes! I feel vindicated after many years of saying no to branching.
  • Really controversial idea on page 240. Probably my only new concept from the whole book. When at the end of your iteration time box any partially done work should be deleted from the code base. If it is important the story will be carried over, otherwise YAGNI. I like how this would seriously focus the team on finishing work like the time box should be and would help with that little bit of time for slack. Reality will likely kick in and I will never see this idea happen.
  • Not much of a focus on operational/BAU/enhancements using Agile. Page 242 is the only one that mentions anything and even then it talks about Daily Iterations or having Batman come in.
  • Stories have moved on since this book was written. There isn’t much in the book about Features and nothing on Epics. There isn’t anything about the standard format. It does have the standard comment that stories are for only business work which is a school that I don’t agree with. What are you calling the IT stuff that has to be done guys?!? It was nice to see that regression defects can be handled through stories (another vindication).
  • I liked the idea that developers should expand their automated test coverage by spending more time watching how end users use the system.

Well, there you have it. One down, ten to go!

Read Full Post »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers