How’s this for a change vision?


“Our vision is to become a firm that pays the very lowest wages possible, charges the highest prices the market will bear, and divides the spoils between stockholders and executives, mostly the latter.”

Does that get you excited about…

  1. Coming to work?
  2. Doing business with this company?

This sample, from John Kotter‘s Leading Change is a reminder that for a vision to work, it has to be seen as something that everyone can get excited about–all stakeholders. And it has to be bold enough to drive people out of their comfort zone, and provide enough focus and targets to make business as usual uncomfortably impossible.

Read about a great example of a vision here.

What does your favorite vision of the future read like? Good or bad?

 

 

 

 

 

 

Trading One Silo for Another


I think we have silo busting all wrong. Well… partially wrong. I recall a story about a university campus. When buildings were put up on campus, there was a deliberate choice to not build any sidewalks or walk paths. Students, staff and faculty moved freely from building to building and over time, paths were worn into the ground where people had walked. The worn paths were the natural walking routes between buildings. Sidewalks were built on the beaten paths.

The usual approach to sidewalks and walk paths is to make straight lines, usually perpendicular or parallel to buildings. They look nice, neat and organized. But they are often not the way people choose to walk from point A to point B. Traditional organization design creates a neat, easy to understand model of how things should work. When it doesn’t work, we re-organize in the hope we are busting a silo. What happens instead is that we create a new silo. Silos are impossible to avoid. We trade one for another.

If instead, we could focus on the paths, we might have a chance of finding something better. In large knowledge-worker enterprises, the flow of information is the real organization. The rules and policies and containers we build are often not respected when something just has to get done. We use our network of trusted colleagues who have access to the right levers and information. When designing an organization, think about the flow of information. Go out into the organization and look for the beaten information paths. Find the “natural networks”, the ones that actually get things done and reinforce them. The challenge is to reinforce them without inhibiting natural change, or without constraining them.

Deliberate Practice – the Leadership Kata


A kata is a set of actions that are assembled in sequence to help you train your mind and body to perform with precision, proper form, and to help you develop muscle memory so that these forms are available to you without thinking. The word “kata” comes from the martial arts. At the Agile2011 conference there was a tutorial titled “The Agile Leadership Kata: Discovering the Practice of Leadership” by Tom Perry. We applied the kata to the practice of leadership. Slides form the session can be found here.

Stephen Denning refers to leadership communication as performance art. All performance requires practice. Katas are a practice tool. Why bother? As a leader, why does it mater if I practice? If my current set of leadership tools are working, do I really need to develop new ones?

Continue reading

Listening Tools


A great TED talk on how we are losing our listening…

Particularly interesting for me was the part on filters that we apply when we listen.  In a world where we we are increasingly broadcasting, Julian Treasure reminds us of the importance of listening, and shares five tools for improving our listening. Enjoy.

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.

Continue reading

Software – Artistic and Innovative Expression


Creating great software is a lot like creating great music. Both require skill, practice, and technical knowledge. Both require creative thinking, collaboration and involve good judgment. Both have an end-customer. Both have a user-experience.

As software professionals we have deadlines. So do musicians. I think about being in a studio, engineer behind the console, producer on the clock, and you gotta create. Pressure… You often hear about the emotional war that takes place between band members, in many respects similar to what software teams go through. You want to add that great new riff you invented, and you search for a place to insert it but sometimes, you just have to save it for another day because it adds weight without value. Similarly, code bloat also occurs because a team member wants to make something cool happen in the code that does not add value. We often hear the words that musicians should “check their egos at the door”. This was made famous by Bob Geldof during Band Aid, the huge Ethiopian famine relief benefit. Bob insisted that the event was not about the musicians, but about helping those in need. As software professionals we can all take a page from that book. Set our egos aside. Create something of value for our customers. Celebrate the success together. Learn from our experience and make the next one even better.

Continue reading

Mike Cohn on Team Structure


I read a blog post by Mike Cohn on the Nine Questions to Assess Team Structure.

Some of the takeaways and questions I found relevant are:

  • Organizations often build short-lived project teams that disband at the end of a project. Is there a way to minimize team churn in this environment? Is it is possible to build cross-functional feature teams that can persist over multiple feature deliveries?
  • Sometimes the need for a specific skill is not required for the life of a project. Some expertise is required to deliver IPSec for example, but the individual with this knowledge could work with multiple teams. How do you enable the skills transfer to multiple people so that no one individual has to be involved with more than 1 or 2 teams?
  • Will your team structure minimize communication paths and enable communication between technical experts who would otherwise not communicate together?
  • Does the team structure make accountability clear?

Creating these teams implies the building of redundant skills and overlap. This helps to create teams with no single point of failure–a necessity for business continuity. Doing so may feel inefficient. The value is reduced project risk, smoother flow, better throughput, and happier teams. If you are forced later to move team members between projects, the redundancy you build in gives you added flexibility and agility.

Creating teams is not just about maximizing short-term value for the project. It is about balancing the short-term needs of the business while building in long-term flexibility and resiliency of the teams and their capabilities to support the goals of your business. Don’t think of this as a trade-off. Think of this as an integrative process that gives you the best of both worlds over time.