Agile Complexification Inverter

First, allow me to lay out some ground rules and a touch of the backstory... I'm not a professional book reviewer, nor paid in any way to read.  But if I could get that gig... I'd be a happy camper.  I've never written a book, but I've hacked out some code, a few articles, some of which might be considered book reviews.  I've worked in the Agile industry for more than a decade (but who's counting), and so - I may be a little close to the topic to have a proper literary impartial bias.  In fact, let me just go ahead and be explicit - I've done this, been there, got the t-shirt; I shit you not - this shit is for real! Agile  Noir  by Lancer Kind Now the ground rules...  I think this review will be written ... what's the word... while I'm reading, at the same time, without much delay in the reading-writing phases.... in situ .... iteratively... oh I give up... So don't be surprised - dear reader - if I just drop off in the middle......

You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering. "When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency." How does this misinterpretation occur?  Why do we humans mess up this simple act of communication? Let's look at an example: For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenur...

Is your "Agile Project Manager" driving the team to increase their velocity?  Has the Agile Death March begun? Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month . One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates.  So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers.  A classic game (Innovation Game) to expose these impediments is Speed Boa t. I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game .  See the article by Alan Dayley  Velocity is Like a Helium Balloon  ...

How do you want to learn about Agile/Scrum?  This question is a 21st century problem.  Only a few years ago (last century) there was practically one way to learn a new skill or domain of knowledge - study via the printed page, e.g. buy a book.  But today we have alternative ways.  And yes they very well may be better at teaching than books.  Heck, I know a woman that learned English by watching cartoon network in Poland. So when people want to learn about Scrum (or Agile - they are not the same thing) I typically ask how they would like to learn.  Do you want a book, or a google search term, or perhaps a video?  Most people are responding to the question with a request for a video. Scrum Training Series (dot-com) Here's my best resource:   http://scrumtrainingseries.com .  The Scrum Training Series is 6 video cartoons that follow a new team into the daily activities and learning of a newly forming team with a Scrum Trainer (facilitato...

Thinking on Jay's suggestion at his presentation  ( DFW Scrum , AgileFest! ) to create an Agile Playbook ; I'm wondering why scrum masters don't do this more often.  Well, guess what?  It's very good advice.  The authors Chip and Dan Heath give this very advice in their new book Decisive: How to Make Better Choices in Life and Work . Why do teams continually over estimate the number of stories they can complete (potentially shippable tested working software) in a sprint?  There are many reasons.  But what play would you run next sprint if you were the team? If your team already has an agile mindset, then the natural play will be to reduce the amount of work they are bringing into the sprint.  The result of this play is to return the team to a consistant delivery of value.  Resulting in a predictable velocity.  This predictable velocity will be used for projecting the release scope or date. The problem for many teams is they ...

So I hear someone say: My company is not thinking of hiring Scrum Masters for the current Scrum adoption initiative that is underway. We appear to have plenty of Project Managers (yet that community believes they need more "heads"). Yes, "heads" is the unit of measure for our "resources."  So the apparent logic that I have explained to me - because I'm just too illogical to arrive at the obvious is ... we will just let the PMs do the SM roll. Right, no problem there. It shouldn't take too much time to do the Scrum Master's job... just a few meetings and that silly 15 minute stand-up each day. Yep - that's the plan. So now lets look at one metric and ask ourselves why this trend is happening.  Let's compare salaries of Scrum Masters to Project Managers.  You can get the   latest info via  Indeed.com .   data from Indeed Salary survey   David Bland (Scrumology) did this some time back and reported that a SM in 2009 average...