Agile Communications
July 21, 2010
“We work with bits not atoms”. This phrase speaks to the distinction of IT projects from physical construction. Our tools and processes manipulate ideas, concepts, and models, not steel, concrete, or plastic. Given the intangible nature of software, it is no surprise we need more focus on communications, collaboration and information sharing to keep everyone informed and aligned towards a common goal.
Agile methods recognize this increased need for communication and provide a variety of tools and checkpoints to help avoid the classic project mistakes of mismatched expectations and confusion. In the absence of a visible physical product to point at and measure, we need to be constantly confirming understandings and aligning ideas against increments of the final solution. Otherwise we get the “That’s not what I asked for” or “That’s not what I need” of yesteryear’s IT projects.
Why So Often?
Daily Stand-Up meetings are common on agile projects, not because IT folk are more forgetful than other workers and need to discuss work goals and results more often; but instead because the potential for misunderstanding is higher when working on novel, hard to describe problems. Stand-Up meetings keep the team informed of work and issues that change quickly and also provide a forum to raise obstacles to progress so they can quickly removed before they unduly impact performance.
Why So Many Demo’s?
Software projects typically contain a lot of uncertainty. You would have to be clairvoyant to accurately predict the final business requirements of an organization 18 months out into the future in today’s rapidly changing business environment. So agile methods accept some requirements are likely to change and rather than have a change control process that should really be called a “Change Suppression Process” they welcome new ideas and then seek priority within a backlog of requested features. Obviously changes cost money, but if it is more important than some previously discussed item, then why not incorporate it and deliver some late breaking competitive advantage?
Agile methods promote the frequent demonstration of software for a couple of reasons. One, to get feedback and make sure it is fit for business purpose. Quite often it is not until we see something that we can better articulate what we really need, now with reference to a visible prototype. Another reason is that it is often during these demonstrations we learn about business changes and new requirements. Many times I have heard comments along the lines of ‘Oh, and for product ABC we will need to way of entering X” when this has been news to us. That’s OK, visual demo’s tap into the right hand side of our brain, not used much in analytical, left brain list making and requirements gathering. It is the combination of lists and visual cues that frequent demo’s provide that create our final views of what the system should encompass.
Why the Focus on the Past?
If agile is so progressive and focussed on possible future changes, the practices of retrospectives where we regularly review how things are working may seem surprising. Every couple of weeks and every release a mini lessons learned review is held to identify want went well, areas of improvement and recommendations for the future.
However, unlike traditional Lessons Learned reviews held at the end of a project and intended to capture useful suggestions for future projects with similar business domain, technical domain, or team dynamics that may never arise. Agile retrospective findings will always be 100% applicable since the same business domain, technical domain, and team dynamics will be in play. It is easy to read previous project’s lessons learned findings and think they will not apply to you, but when raised by your own team members and focussed on the last two weeks, these cannot be ignored or conveniently forgotten. They apply and are timely; you need to go implement them right now.
So, agile retrospectives are an extension of learn and adapt values we apply to the software development. They acknowledge that we do not have all the answers up front and instead will try things, evaluate their results, and adapt as we progress to continually improve.
Why so much business involvement?
Getting the business involved in requirements gathering is fundamental, having them there for regular increment demonstrations and feedback seems sensible. However, why get them mixed up in the planning and prioritization; surely this is a receipt for disaster?
Business engagement in planning and prioritization is critical for acceptance of late breaking changes. Without the business being in charge of the prioritized backlog they would not be as amenable to the inevitable trade off discussions that they require. So, the business is invited to iteration planning meetings where work for the next iteration is confirmed. With increased involvement comes increased commitment to a goal, and often the business become powerful advocates for defending project resources and budgets.
But do we need all this communication, really?
In Francis Hartman’s book “Don't Park Your Brain Outside: A Practical Guide to Improving Shareholder Value With Smart Management” project failures and their link to communication failures are investigated. Hartman asserts that “100% of project failures can be attributed to communication failures” the failed projects he investigated can be traced back to a failure to communicate a issue, concerns with estimates, or some attribute of the project that would likely have been resolvable if the right people had communicated early enough.
Agile’s focus and sometimes seemingly over focus on communicate, communicate, communicate via Daily Stand-Up, demo’s, retrospectives, planning sessions, pairing, group based estimation, etc all help address this root cause of project failure – not enough communication. In fact do not be afraid of over communicating. In Jim Collins’ “Good to Great” book Collins reports that the “Level 5” leaders of the Great organizations who play a big part of their companies success spend a disproportionate amount of their time communicating compared to the not so great leaders in other companies.
IT projects have plenty of opportunities for confusion and misunderstanding. We are building a novel, intangible solution, to a probably never before tackled business problem in that organization. Communication is the key, and agile methods provide many great opportunities to communicate frequently throughout the project to a variety of stakeholders. Use them and reap the rewards of fewer misunderstanding and happier stakeholders.
If agile is so progressive and focussed on possible future changes, the practices of retrospectives where we regularly review how things are working may seem surprising. Every couple of weeks and every release a mini lessons learned review is held to identify want went well, areas of improvement and recommendations for the future.
However, unlike traditional Lessons Learned reviews held at the end of a project and intended to capture useful suggestions for future projects with similar business domain, technical domain, or team dynamics that may never arise. Agile retrospective findings will always be 100% applicable since the same business domain, technical domain, and team dynamics will be in play. It is easy to read previous project’s lessons learned findings and think they will not apply to you, but when raised by your own team members and focussed on the last two weeks, these cannot be ignored or conveniently forgotten. They apply and are timely; you need to go implement them right now.
So, agile retrospectives are an extension of learn and adapt values we apply to the software development. They acknowledge that we do not have all the answers up front and instead will try things, evaluate their results, and adapt as we progress to continually improve.
Why so much business involvement?
Getting the business involved in requirements gathering is fundamental, having them there for regular increment demonstrations and feedback seems sensible. However, why get them mixed up in the planning and prioritization; surely this is a receipt for disaster?
Business engagement in planning and prioritization is critical for acceptance of late breaking changes. Without the business being in charge of the prioritized backlog they would not be as amenable to the inevitable trade off discussions that they require. So, the business is invited to iteration planning meetings where work for the next iteration is confirmed. With increased involvement comes increased commitment to a goal, and often the business become powerful advocates for defending project resources and budgets.
But do we need all this communication, really?
In Francis Hartman’s book “Don't Park Your Brain Outside: A Practical Guide to Improving Shareholder Value With Smart Management” project failures and their link to communication failures are investigated. Hartman asserts that “100% of project failures can be attributed to communication failures” the failed projects he investigated can be traced back to a failure to communicate a issue, concerns with estimates, or some attribute of the project that would likely have been resolvable if the right people had communicated early enough.
Agile’s focus and sometimes seemingly over focus on communicate, communicate, communicate via Daily Stand-Up, demo’s, retrospectives, planning sessions, pairing, group based estimation, etc all help address this root cause of project failure – not enough communication. In fact do not be afraid of over communicating. In Jim Collins’ “Good to Great” book Collins reports that the “Level 5” leaders of the Great organizations who play a big part of their companies success spend a disproportionate amount of their time communicating compared to the not so great leaders in other companies.
IT projects have plenty of opportunities for confusion and misunderstanding. We are building a novel, intangible solution, to a probably never before tackled business problem in that organization. Communication is the key, and agile methods provide many great opportunities to communicate frequently throughout the project to a variety of stakeholders. Use them and reap the rewards of fewer misunderstanding and happier stakeholders.
Don’t be afraid to switch away from your original core business when the revenue starts to tank. Unlike what Jim Collins preaches in his books, Adam Hartung has proof there is a different approach
http://bit.ly/dwdZ15
Posted by: Ryan | July 22, 2010 at 12:41 PM