Speaking @ Agile 2011 – Salt Lake City, August 8-12 2011

I’ll be presenting “Cultural Architecture” at the Agile2011 Conference in Salt Lake City this August. Here’s an overview of the talk.

If our business culture was a product, how would we re-architect it? Culture influences everything. So how can we influence culture? What tools help us understand cultural influences, from the implicit, the elements we don’t even think about, to the visible, the artifacts that lead to stereotypes? Adopting an Agile culture, when it is under-laid with the cultures of the world is challenging. Reconciling cultural dilemmas drives collaboration and innovation. Culture is the core of it all. Knowing this, you can create a pull for cultural change in your organization.

Read more of this post

How Adopting Agile can Lead to Business Failure

For Agile veterans, this list of failure reasons is not new. But it never hurts to be reminded of what they are.  So here is the list by Clinton Keith and Mike Cohn. I wish everyone would read this list and post it on their bathroom mirrors. You can find the source document here.

  1. Don’t trust the team or agile. Micromanage both your team members and the process.
  2. If agile isn’t a silver bullet, blame agile.
  3. Equate self-managing with self-leading and provide no direction to the team whatsoever. (Good leadership always matters!)
  4. Ignore the agile practices. They don’t apply to management. (As a manager and leader, this is my favorite.)
  5. Undermine the team’s belief in agile.
  6. Continually fail to deliver what you committed to deliver during iteration planning.
  7. Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
  8. Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
  9. Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily stand-up.
  10. Don’t communicate a vision for the product to the team or to the other stakeholders.
  11. Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
  12. Replace a plan document with a plan “in your head” that only you know.
  13. Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.
  14. Start customizing an agile process before you’ve done it by the book. (Another favorite of mine.)
  15. Drop and customize important agile practices before fully understanding them.
  16. Slavishly follow agile practices without understanding their underlying principles. (I call this one Agile-By-Rote).
  17. Don’t continually improve.
  18. Don’t change the technical practices.
  19. Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
  20. Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

Perfection and Pragmatism

This is a long post, so here is the digest version first.

  • Develop a vision of perfection for your Agile business that includes the product AND the people that create it.
  • Think about what it feels like to work in this perfect Nirvana – engage your right brain.
  • Start moving toward that vision now as fast as you can without losing control – be pragmatic.
  • Be prepared to suffer some mental pain along the way – so eat cookies and drink milk.

That’s it. The rest of the post is some ranting to prime some thinking.

Read more of this post

Mature Scrum

This is a follow-up post to Dinner with Jeff Sutherland, where Jeff talked about Systematic and the two LEAN metrics for driving improvements; 1) Process Efficiency, and 2) Fix time after failed builds. More details are now available in a paper titled Mature Scrum at Systematic.

Systematic combined a LEAN operating model, SCRUM as the project management framework allowing for flexibility and adaptability, and CMMI to institutionalize these elements into the culture of the organization, driving discipline and measurability. More information as well on how User Stories are prepared to a READY-READY state before being allowed to enter the Sprint. The grooming of the backlog and preparing User Stories is done in parallel to the Sprint.

March 29 2010 – Dinner with Jeff Sutherland

Monday, March 29, I had the opportunity to have dinner with Jeff Sutherland and other RTP leaders. The dinner was a fundraiser for CITCON, which came to RTP in April. This was an opportunity for Agile practitioners and experts to have an informal chat about the challenges and opportunities of using Agile in the world of work.

I was interested in learning more about Systematic, a CMMI level 5 company that implemented Scrum across its entire business. One thing that sets Systematic apart from other companies is that it has really good data to prove that Scrum works, and it is a software company that can execute perfect waterfalls every time. Systematic created hyper-productive teams, and by Jeff’s definition, they are at least 4 times more productive than industry average. They cut TTM in half and the development costs by the same as well.

Read more of this post

A-TDD as an Efficient Design Tool & Productivity Booster

Been thinking a lot about A-TDD these days with ICST and the TDD workshop coming up next week. A-TDD can help you do more than validate your product against Acceptance criteria. A-TDD asks you to think about the definition of Acceptance in Customer terms, and prepares you to be Ready-Ready. This represents the black-box product tests that customers will run. A-TDD covers not only functional tests, but also covers tests related to performance, stability, reliability, security, and other “-ility” tests. A-TDD can help you do the following as well:

Read more of this post

Scaling Scrum: Lessons from the Trenches

While in Paris, I had the opportunity to attend a talk by Scott Ambler, a fellow Canadian, on “Scaling Scrum – Lessons from the Trenches”.

Scott’s view is that Scrum by itself is not a complete solution for product development, which of course is true (duh!). The front end and back end of the business process also need to be involved and there needs to be some governance structure in place among other things to make sure a large distributed and complex development activity can be executed using Scrum and other Agile methods.

Read more of this post

3GPP LCS Feature example using Component versus Agile Feature Teams

Feature teams as opposed to component teams allow you to organize in a way that maximizes architectural integrity and business value demonstration at the User Story level, and ultimately, at the feature level. Check out Catherine Louis’ slides on how to organize around a complex, multi-network element feature in the telecom domain. Really great work. You can find them here.

Thanks, Catherine, for sharing!

Conway’s Law and the Impact to Product Development

Melvin Conway introduced an idea in 1968:

…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

Think about your product and it’s strengths and weaknesses. Can these strengths and weaknesses be mapped to the strengths and weaknesses of the communication paths in your organization? Component-based teams and human relationships are at the core of this idea. Read more of this post

British Telecom’s transition to Agile

Interesting article on British Telecom’s transition to Agile which started back in 2004. The article was published in the Summer 2006 issue of Methods and Tools.

You can find the article here. When I read it, it feels sooooo familiar!

Follow

Get every new post delivered to your Inbox.