Monthly Archives: August 2014

Gaining Support for Agile

Team and Leader at opposite sides of see-saw.

renjith krishnan –

Trying to move to an Agile organization is an interesting endeavor. On one hand trying to be Agile without management or executive buy-in almost always fizzles before it reaches critical mass. On the other hand trying to force Agile down from above tends to result in teams going through the motions until management abandons the attempt and returns to status quo while awaiting the next trend. To succeed in an Agile transformation everyone needs to be on board and willing to change.

If you are trying to push Agile up in your organization there are right and wrong ways to do it. Starting out an Agile transformation by telling your manager that the team needs to be self-managed will likely give a negative initial opinion to them. You basically told them you want to cut them from the team. Instead think of what supports the organization. Sell Agile as a way to provide better value faster. Notice I didn’t say more value. It needs to be clear that generally the team will deliver the same “amount” of stuff. The difference is that an Agile team will generally deliver more relevant stuff than a non-Agile team. Over time this might have the feel of more stuff. It might even, in a high-performing Agile team setting, be more stuff. It will likely not be significantly more though, so leave that out of the sales pitch.

Likewise dictating Agile to teams is not always an easy proposition. Think of how it is sold. Most organizations that decide they are going Agile today will send their PM’s to Scrum training, institute a bunch of meetings, and expect “better” results. One problem occurring is that they aren’t really open to change. Management wants the team to change their processes, but will not let the team drive that change to what works best for them. The team is expected to do all the changing in this transaction. The failure points should be clear when management steps back. Agile pushes teams to self manage; let them figure out the right process. Give them the goal, sell them the vision, and let them deliver. In return, be open to feedback from the process. Support the team in their attempts to deliver, even if it means change. That doesn’t mean bend to their will, but have open discussions and show willingness to change when it makes sense.

Most Agile methodologies and frameworks will expose problems with the current way of working. Some problems will be at the team level, some will be at the management level. Both parties need to be willing to acknowledge the problems and work through them for the Agile transformation to succeed. Agile transformations are going to be hard. Any change is generally hard, and truly embracing Agile will likely drive significant change. Bringing the entire organization on board will ease the transition, leaving half of it off will stifle it.

Experience or Certification?

Hand drawn Illustration of a white chicken and egg perched on a branch of a tree, set on a plain yellow coloured background.

Simon Howden –

While LinkedIn seems to have a low signal to noise ratio there are some good discussions. I think part of the problem is people like me. I’m willing to put myself out there. I try very hard not to miss-inform people as I learn, but I may make mistakes on occasion. The important thing to me as a creator is that I want to “own my thoughts.” As a reader on LinkedIn I’m leery of external links and people posting back to their own blogs. I’m generally willing to click it and see, but find myself more sensitive to sales and corporate sites this way than via other blogs.

All this is to say that it seems the always popular subject of Certifications versus Experience has come up recently. The responses are pretty much what you would expect from industry professionals. Experience is what really matters. Certifications don’t mean a person is good at a job. A general feel that certifications mean you can study for and pass a test, and not necessarily much else. Continue reading

Where does Kanban fit?

Empty chairs at office.

adamr – FreeDigitalPhotos.Net

Kanban is a change method I have not had the opportunity to employ here. I wish I could though. The apparent simplicity appeals to me. That’s not to say that Kanban is going to make life simple. Deciding to use Kanban in your project should not be taken lightly. If you thought Scrum exposed issues in your process just wait.

Most of us have heard of Kanban. We’ve likely even heard that it comes from lean manufacturing efforts at Toyota. I’ve written about it briefly before here and here. Our own burn-down chart has a level of resemblance to a Kanban board. A different team here is trying to use it as a primary work process. Even with all that I think we miss the point here, and maybe you do too. Continue reading