Tag Archives: Agile Enterprise Solutiions

Was Steve Jobs an Effective Agile Leader?

Was Steve Jobs an effective Agile leader? I watched the movie “Jobs” this weekend about the life of Steve Jobs and his career at Apple and it was very thought-provoking.  Steve Jobs was absolutely brilliant, embodied a lot of Agile values, and he was enormously successful in developing some very innovative products in a relatively short amount of time that made Apple very successful;  but he was ruthless, tyrannical, and very insensitive in his relationships with people.  I was thinking – is that style of leadership really consistent with Agile and is it an effective style of leadership for an Agile environment?

  • Much of the thinking behind Agile is based on the idea of empowered and self-organizing teams where the product definition bubbles up rather than being driven down from above,  Steve Jobs’ leadership style doesn’t seem to be very consistent with that model, but he was very successful in getting things done.
  • Another thing that seems to be not entirely consistent with Agile is that Agile is based on the idea of teams working at a “sustainable pace” and it was apparent that many of the teams that worked under Steve’s direction at Apple worked incredible hours to get things done but they were very passionate and dedicated to their work.

Here are some quotes from Steve Jobs that indicate his values that are related to Agile:

  • Focus and Simplicity – “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things…
    “That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
  • Planning – “Again, you can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something – your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.”
  • Quality – “Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
  • Innovation – “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
  • Requirements and Customer Needs – “You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new
  • Seeing the “Big Picture” – “A lot of people in our industry haven’t had very diverse experiences. So they don’t have enough dots to connect, and they end up with very linear solutions without a broad perspective on the problem. The broader one’s understanding of the human experience, the better design we will have…To turn really interesting ideas and fledgling technologies into a company that can continue to innovate for years, it requires a lot of disciplines.”
  • Continuous Improvement – “I have a great respect for incremental improvement, and I’ve done that sort of thing in my life, but I’ve always been attracted to the more revolutionary changes. I don’t know why. Because they’re harder. They’re much more stressful emotionally. And you usually go through a period where everybody tells you that you’ve completely failed.”
  • Tools – “It’s not the tools that you have faith in – tools are just tools. They work, or they don’t work. It’s people you have faith in or not.”
  • Leadership Style – “It’s not about charisma and personality, it’s about results and products and those very bedrock things that are why people at Apple and outside of Apple are getting more excited about the company and what Apple stands for and what its potential is to contribute to the industry…The people who are doing the work are the moving force behind the Macintosh. My job is to create a space for them, to clear out the rest of the organization and keep it at bay.”

And one of his most famous quotes that really sums up his values is “Stay hungry, stay foolish”.  The source of the above quotes is:

http://www.brainyquote.com/quotes/authors/s/steve_jobs.html

My thoughts on this are that:

  • Steve Jobs definitely had some “rough edges” in his relationships with people but he embodies many of the characteristics of an effective Agile leader
  • There probably isn’t one leadership style that is effective in all situations and some “out of the box” thinking is definitely worthwhile rather than implementing some kind of “textbook” Agile approach in all situations

What do others think?

 

What Does it Take to Become an Agile Developer?

What does it take to become an Agile developer? I recently was in a situation where the development team was completing tasks required for a sprint, but the overall stories were not being completed. The team allocated development tasks to individual developers and also allocated overall responsibility for each story to individual developers. However, for several sprints, the development tasks were completed but a number of the stories were not.

I don’t think the developers on the team clearly understood what it meant to be responsible for a story. I think most saw their primary responsibility as completing development tasks. Completing stories was seen as kind of an administrative coordination function. It’s more than that, in my opinion – a developer who takes responsibility for stories in a sprint needs to be responsible for:

  • Understanding the business purpose of the story and defining and analyzing possible alternative ways of satisfying the business purpose of the story
  • Planning and estimating development tasks with other developers that are required to fulfill the story
  • Working directly with the Product Owner to clarify and further define the details of how the story should be implemented
  • Providing guidance to other developers as necessary who are engaged in development tasks associated with the story
  • Taking overall responsibility for “shepherding” the story through the process all the way to (and including) UAT. The developer responsible for the story should lead the presentation of the completed story to the Product Owner in UAT (or Sprint Review)

I think it’s sometimes taken for granted that any developer can easily move into an Agile project – I don’t believe it’s that simple and my experience is that some developers have a hard time making that transition. Some developers just want to write code and are not even interested in taking on these additional responsibilities.