Below is the presentation I gave at STC (Society for Technical Communication) Management Day in Toronto last week. Technical communications as a field is moving out of just documentation into more value-added activities such as facilitating shared understanding and agreement between diverse groups. As well, getting involved early to reduce documentation required by helping ensure software aligns with users needs.
I first read Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising when it first came out many years ago as part of Scrum Toronto book reading club. It has been an important source of ideas that have allowed me to successfully adopt Agile at many companies. This is an essential part of any change agent’s toolkit.
Mihai Iancu has a wonderful mindmap to show the patterns in a visual an approachable manner. Thanks to Mihai for allowing me to share this with you.
Here are some of my favourite patterns:
Please comment on yours.
Ken Schwaber has a great presentation where he talks about the Innovator’s Dillemma and how companies build a (design) dead core.
BUT, this is a horrible long term strategy because you get a design-dead core and can no longer ship product.
Innovator’s Dilemma
The purported dilemma is that you need to choose between fast delivery and maintainability. So, if you want to get to market fast you need to take shortcuts that are going to hinder you in the long run.
This is also called the inventor’s dilemma.
Teams that follow Agile practices avoid this peril in two ways.
By managing features and scope, teams can find the most valuable software to deliver by a certain date.
Technical practices such as automated testing, continuous integration and refactoring keep a code base healthy and maintainable. They also helps teams go faster.
Consider the chart below. Companies start at burndown line A. If they use Agile, they will stay there. Most companies don’t. So, release by release, they accumulate technical debt and the code base decays. After a few years, they build a design-dead core.
As a coach, I like to show teams the chart below and vote on their code base. Many companies are at line C with some area’s that are D.
OK, so you’ve got a dead core. Sad news. There are ways to recover. I’d suggest you start with Michael Feather’s book Working Effectively with Legacy Code.
The whole video is great, but for the part explaining the Innovator’s dilemma check out:
One of my goals is to make a mindmap of every book that I read. I figure if I can take the time to read it, I may as well take a little time to synthesize the content of the book into a mindmap so I can remember it later. Seems like a good idea, and this is the first one in what I hope will be a long and informative series.
So, today’s review is on Why We Make Mistakes – a book that describes failure modes common to people. Many of my regular readers will be wondering what this has to do with Agile and Lean, but it turns out that there are several direct links to industry practices.
Last fall, I had the opportunity to hear Ross Pettit and Jane Robart present at the ThoughtWork QTB in Toronto. You can see the full presentation and slides on InfoQ. (Hint: if you are in Toronto, there is a talk on Legacy Systems coming up on Friday, Feb 5th).
The most memorable phrase from the presentation is: All IT projects are a voyage of discovery. This seemed to be a very salient way to express learning and communication are key. Check out my drawing of a boat 
So the talk is all about governance - how do we ensure that our projects are succeeding? There really isn’t very much in there about the PMO’s role and for that matter about Agile. Still some very interesting points…
One aspect of governance is making sure we have the right people in the right roles since IT is a people business. The reality is that most managers tend to stick with people even if they aren’t working out in that role. One idea is to use net promoter score: would you recommend a colleage for another project?
Another key idea is independent steering committees. In many cases the stakeholders (usually senior management) are on the steering committee for a project that they are sponsoring. Well, you know what happens when there is a conflict of interest. I’ve seen it happen first hand recently and it wasn’t pretty.
Finally, good steering committees have a breadth of talent that can function as a team to dig into the project data and ask tough questions. They need the right set of lenses to view the project from different perspectives – technical, financial, customer, etc.
Overall the talk was quite informative since I have seen lot’s of room for improving governance at most organizations I have worked at.
Scott Ambler gave the keynote at Agile Tour Toronto this past Fall. As a conference organizer I only caught part of it, but still there were some useful perspectives that I wanted to share. Scott’s presentation is here.
Scaling Factors are about the kinds of things that make software projects more difficult (whether using Agile or not). Each of these factors require additional considerations that are outside of basic Agile practice. I find this a nice way of thinking about project complexity since this directly maps to the challenge with adopting Agile.
There are no repeatable projects.
There are no repeatable projects. I thought that was worth repeating since a lot of organizations still don’t understand that each project has a distinct signature and may require a different approach: Standardization is a good recipe for failure. Reading between the lines this seems to be a shot at PMO’s that are mandated to standardize software delivery.
Mike Cohn placed a challenge on his blog for people to describe a Waterfallacy – “A waterfallacy is a mistaken belief about agile that has been caused by prolonged exposure to the waterfall process.” This is to promote his new book – Succeeding with Agile. I have found it very useful in my Agile work and would like you to consider ordering it now to succeed with Agile 
I have run up against this waterfallacy many times. Here are some of the things I have heard:
The assertion is that there is little or no documentation in Agile and the implication is that Agile cannot possibly work.
How to overcome these statements? I talk about 4 things:
In the Agile Manifesto we talk about valuing working software over comprehensive documentation. So, working software comes first since that is what will make our businesses succeed. The manifesto does not say to avoid documentation entirely – that’s a mis-read!
One of the key Agile Principles is:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This signals that people should talk to each other rather than communicating through documents. Does it say not to document? No!
Agile teams tend to use wikis as a lightweight and searchable knowledge base. They document things that they think are important or useful. It may be text, photos, diagrams. For more info on how to make this work, check out this article on Agile Modeling.
Most of the Agile teams I work with produce a lot more useful documentation than more traditional teams I have worked on.
If you use Scrum, let me remind you that Scrum is completely silent on documentation. It’s up to the organization to decide how much and what types of documentation need to be completed every Sprint.
Usually people are convinced at this point and say – “Wow! I didn’t know that.”
Yves started the Agile Retroflection of the day project for 2010. Today’s question is “When would you choose to value process and tools over individuals and interactions?”
Strangely, I find myself in a situation where I need to place a very high value on process to provide shock therapy to a client that is in the whirlpool at the end of the waterfall.
It’s the usual software story of an over-full release with a fixed release date required by not one but two external customers. Add to this a chaotic process and broken telephone between functional groups. The interesting question posed by the client is this: “Is there anything you can do to help us?” (What would you say?)
Given the timelines and pressure, there is no way I know how to do Agile in a conventional way. So tomorrow, I am launching what Gerry Kirk and I called Guerrilla Agile – something light and tactical. To make this work, I will need to very directive in what needs to happen. The main goal of this phase is to get shippable software. A later phase is planned for a sustainable transition to Agile.
In terms of my training budget, I figure I have at most 3 hours. Here the emphasis will be on cross-functional teams and working together. So in this sense I am valuing people and interactions over process - not the other way around. Perhaps the title of this post is backwards: maybe all the command and control around process is just a smoke-screen so I can focus people on what’s important: teamwork.
P.S. Given all the passion and energy around Kanban and Scrum these days, I think it apropos to mention that we’ll get started with Kanban since even 1 week long sprints would be to big a challenge in the current environment.
I am very happy to announce that Michel Goldenberg (CSM, CST) and I will be running some public training in February in downtown Toronto (Residence Inn Mariott at 255 Wellington St West).
This is a great chance to learn from not one but two experienced Agile coaches. If you know anyone who might be interested, please let them know.
Yesterday, Gerry Kirk and I kicked off a 4 day Agile Assessment with a presentation aimed at taking some of the uncertainty out of Agile and providing context for the transition/assessment. See slides below.
The values and agile project life cycle slides were not show; instead, Gerry did a live diagram construction (see photo below). This approach worked well and we got lot’s of great questions.
One of the questions was about Agile contracting. There is a good presentation I commented on in a recent post.
Subscribe
| Log in |