I try to live my life in an Agile-manner. Iterative improvement, utilize a personal kanban board to manage home-work, Product Owner buy-in (wife), etc.
You see, there is a problem at home. There is a larger-than-a-basketball wasp nest 3 stories up with no access to the roof. [This could get messy…]
Is there anything in the Agile Manifesto that talks about:
- Shaking problems to the point where they go away?
- What about shooting problems to see if they go away…
- How about spraying problems with water?
- Paying contractors lots of moola to do your work for you?…
Inspect and adapt. Yes. I get the inspect part. I’ve inspected it enough. Now its time to… adapt? Hell no. It’s time to go Judge Dredd on it!
What do you think?
What is the most Agile and safe way to solve this personal conundrum?
Throw Away Your Steering Committees!
The National Australia Bank (NAB) has recently thrown Steering Committees in the garbage and taken on a more Agile approach to product development. Australian CIOs advocating the Agile software development model have embraced a “behind the scenes” management role to facilitate faster, more flexible teams. Projects no longer involved steering committees and those C-level representatives find them a “a waste of time.”
Rob Thomsett, currently a consultant to the National Australia Bank (NAB), said the bank had adopted Management 2.0 (Management 3.0 anyone?) principles in an effort to reduce bureaucracy and improve speed to market.
“These [executives] want things to happen faster; they want to be successful, they want to trust people… Being first to market in the banking sector is a really important thing … Some of the new products that these banks are working on will blow your socks off.”- Rob Thomsett
While banking technology lasted an average of four years in the 1960s, 70s, and 80s, contemporary organisations were deploying new products in under three months, Thomsett goes on to say.
So if banks can do it… can the financial, health care, and insurance industries of America utilize Agile too? Is there no area of the world where Agile isn’t taking a hold?What can stop this undeniable force of nature that is Agile?
Stop the madness! AGHHHHH!!!
[Guest Post: Paul Boos serves as the software maintenance lead for the Environmental Protection Agency’s Office of Pesticide Programs (OPP). His team currently uses Kanban and Scrum to maintain the OPP legacy code base. Prior to that he implemented Scrum as the Branch Chief for the National Development Branch within USDA/Rural Development. Follow him on twitter: @paul_boos]
5 Characteristics of the Innovation Personae:
Creating a Culture for Government Innovation following the Feng Shui
In my prior post I laid out the framework (using Feng Shui) for creating a culture of innovation in the Government. In this post, I’m going to specifically discuss what characteristics one needs to nurture in the people that are a part of the organization.
Innovation as had previously been defined is the ability to create change, not just adapt to it. Innovation usually deals with adapting a product or service or creating a whole new product or service. To do this requires Learning.
I’ll be referencing a few “process” views from Lean Start-Ups as whether they ventures are successful or not, they are generally considered innovative. Let’s start with the “Lean Circle” as shown in Figure 1.
Here one finds that the blue circles indicate concepts or results form an activity. In established organizations, which would include all Agencies in the US Federal Government with the exception perhaps of the new Financial Consumer Protection watchdog, this will always start with examining existing products or services.
The first activity is Learning
This generates ideas about new products or services or to improve existing ones. Every activity and product that the organization has done up until this point, whether following the Lean Feedback Circle or not, has been building experience. Thus not only will one want to nurture learning, but Learning through Experience. This doesn’t mean that the people in the organization won’t look outside the organization in their learning, but it will have the context of the experiences they have essentially been living. One should note that this is different than Learning from Experience; that essentially implies that someone could examine case studies or lessons learned and build innovation. This is less likely to be as effective as those that actually were currently performing work and living the experiences. Continue reading “5 Characteristics of the Innovation Personae”
Agile can sometimes be equated with faster time to market and success. For those that have authored books, you know that the publishing cycle can not only be brutal, but time consuming as well. I believe the reason eBooks are on the rise is because of some very Agile practices. My suggestion would be for publishers, as they (hopefully) evolve, would move more into services. What do I mean by that? HELP THE SELF-PUBLISHED AUTHOR get his book out the door quicker. Sounds like a new consulting market to me… 🙂
Top 10 Reasons Publishers Should Adopt Agile
- Revenue – The iterative nature of Agile development means features are delivered incrementally, enabling some benefits to be realized early as the product continues to develop. Get that money early. For ePub folks, that means publishing online, piecemeal. That’s what I did.
- Speed to Market – Research suggests about 80% of all market leaders were originally first to market. As well as the higher revenue from incremental delivery, Agile development philosophy supports the notion of early and regular releases. Keep the interest going. Build up a brand, build up exposure. Get the word out and grow.
- Quality – A key principle of Agile development is that testing is integrated throughout the development lifecycle, enabling regular inspection of the working product as it develops. Sometimes it’s only possible to detect issues or potential problems when you can really see a feature working. It’s not always as obvious from a paper specification. For the book I wrote, I did it in an iterative fashion. Pushed the book out, made adjustments, inspected, adapted, made more changes.
- Visibility – Agile development principles encourage active user involvement throughout the product’s development and a very cooperative collaborative approach. Get feedback from people. Get feedback from publishers, editors, copywriters, your community. Active engagement with your audience and market could provide valuable insight. Plus, who wouldn’t want to read a book that they have helped create (crowd sourcing anyone)?
- Risk Management – Small incremental releases made visible to the product owner and product team through its development help to identify any issues early in the project, or at least as they arise, making it much easier to respond to change. Don’t put all of your 9-12 months of writing to risk or chance! We move projects away from huge builds and huge roll-outs… why are we still doing it with paperback books?
- Flexibility – Change happens. Simple enough. As I went forth into writing my book, I found that there were extra things I needed to add here and there. There were even full chapters that I wanted to add late into the game. Well, since I was working in an iterative fashion, I simply added them in. No harm done!
- Cost Control – For authors, cost can be seen as time. Writing a good book is expensive. Hell, if you have enough written, why not just push it out with a lot of polish? If you’ve reached your (say, 6 month time frame), polish what you have, push it out on a blog. Keep iterating on it until you have a full book. Then publish that.
- Business Engagement – The active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. You need a good editor. Period. Get one. Keep them in the loop. But leverage them when you need help on certain pieces of your work. The more input they have, the better your product will be.
- Right Product – The ability for the book to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the author is much more likely to write the right book, tailor it to your audience, and make sure it is done well.
- Fun – Book writing shouldn’t be a drag. If you’re not having fun. Don’t do it. Agile methods allow you to pace yourself, get the right amount of feedback, decrease your risk, and open up the world of possibility for change. When I was fielding publishers for my book, I got a lot of denials. I also got a lot of “We’d love for you to write for us, please make your book 200-300 pages.” Eh? Yep, that wasn’t exactly what I was going for. I used Agile and began #winning at publishing. You can too.
Feel free to email me or post any questions on this post about how I published my book.
A couple of articles came across my desk that I thought were worth distilling for easier consumption. They both revolve around selling Agile and subsequently funding Agile projects.
In terms of monitoring the costs associated with an Agile project, one should consider:
By capturing task effort associated with completed stories, we can start to correlate story points with cost. Burndown charts can be annotated with the loaded cost of completed user stories (remember a story is either done or not done, nothing in between). Having developed a correlation with story points and delivery cost we are better placed to forecast the cost of delivering the remaining backlog at any given time.
Effective agile development depends on effectively monitoring changes in the business environment. What processes and methods should companies put in place to effectively monitor dynamic changes? How do you know if you are getting it right?
Agile development is a closed feedback-loop system, and the single most important part of that loop is business feedback. To formalise this we can use John Boyd’s Observe, Orient, Decide and Act Loop (OODA) cycle, below:
When selecting a project for David Norton from Gartner says to ask the following: Continue reading “Selling Agile to the CFO and Funding Agile Projects”