Increasingly, I am becoming concerned with how Scrum is being perceived, adopted and implemented. I've read a number of blogs bemoaning the fact that the fundamentals of scrum are not being followed, and then when the process is followed the mindsets are not shifting.
Scrum is just the beginning of the transformation of software development for a company. Implementing the Scrum process correctly is the critical foundation. Don't leave retrospectives out, or do scrum every other day, just follow the whole process as defined.
Once you've established and are following the scrum process other less tangible changes will take place. Individual team members will experience a change and shift in their mindset and perspective, teams will change their culture, velocity will increase and then you'll hit the next brick wall...
Product quality and the ability to adapt it. This is where Scrum needs Extreme Programming practices, a company can run Scrum well and still have poorly architected and constructed code with high costs of on-going support, and low levels of flexibility.
So Scrum and XP coding practices need to be adopted. When you're up and running with Scrum & XP you've come along way... But then the next level of complexity hits you.
Your velocity as a programme or department is out-stripping the rest of the business. I.e. Support teams can't keep up, or procurement can't handle the speed of decisions or respond to impediments, or the business hasn't the capacity to support the development etc.
At this point, I think its time for Lean Thinking. Lean thinking is a tried and tested approach to rapid business improvements across multiple verticals. It is coached in business terms, using business language, and rapidly transposes both into agile software development and other departments across the enterprise.
Scrum is not the goal, an agile, adaptive, responsive supply of products and services to our markets is what we're trying to achieve. You need Scrum, XP & Lean thinking!
Friday, November 20, 2009
Wednesday, November 18, 2009
"Launch, launch, launch..."
What follows is a suggested approach to tackling impediments on the critical path within a scrum environment.
In another life, I was in the Royal Navy serving at sea in an operational environment, and we used to "play" war games. During a war, the control of the ship shifts from the captain and the bridge to the Ops Officer and the Ops room.
Various teams across the ship are working on understanding the threats to the ship and the opportunity to attack targets. The sonar team will have contacts that they are assessing, radar will be picking up contacts, communications intelligence will have information on aircraft chatter etc.
The Ops team are assessing threats in real-time and the individual teams are all working on providing more information to the Ops Officer on when to launch weapons or countermeasures...
"Missile away"
"Launch, launch, launch, bearing 274 degrees"
Upon a communications analyst hearing missile away on aircraft chatter, they scream that a launch has occurred and the bearing. The Ops Officer then turns the ship towards the missile to present a smaller target and the entire ship focusses on the immediate threat...
I'm currently working with a team who ARE the critical path for a major programme of work, we're hitting impediments on a daily basis and have adopted an approach similar to the above.
As soon as an impediment is hit, we pair up. (Alot of people will already be pairing). The pair is then time-boxed at 20mins to identify potential solutions and move to resolution. If no resolution is on the horizon within 20mins, the entire team stops, the problem is white-boarded and discussed to identify a way forward.
The negative side is the 30 mins that could be lost for the entire team during this period which is why I would only suggest this for critical path items. However the benefits are transparency, lots of minds on a single problem, sharing the load and risk, building team cohesion.
Just a thought for your toolbox.
In another life, I was in the Royal Navy serving at sea in an operational environment, and we used to "play" war games. During a war, the control of the ship shifts from the captain and the bridge to the Ops Officer and the Ops room.
Various teams across the ship are working on understanding the threats to the ship and the opportunity to attack targets. The sonar team will have contacts that they are assessing, radar will be picking up contacts, communications intelligence will have information on aircraft chatter etc.
The Ops team are assessing threats in real-time and the individual teams are all working on providing more information to the Ops Officer on when to launch weapons or countermeasures...
"Missile away"
"Launch, launch, launch, bearing 274 degrees"
Upon a communications analyst hearing missile away on aircraft chatter, they scream that a launch has occurred and the bearing. The Ops Officer then turns the ship towards the missile to present a smaller target and the entire ship focusses on the immediate threat...
I'm currently working with a team who ARE the critical path for a major programme of work, we're hitting impediments on a daily basis and have adopted an approach similar to the above.
As soon as an impediment is hit, we pair up. (Alot of people will already be pairing). The pair is then time-boxed at 20mins to identify potential solutions and move to resolution. If no resolution is on the horizon within 20mins, the entire team stops, the problem is white-boarded and discussed to identify a way forward.
The negative side is the 30 mins that could be lost for the entire team during this period which is why I would only suggest this for critical path items. However the benefits are transparency, lots of minds on a single problem, sharing the load and risk, building team cohesion.
Just a thought for your toolbox.
Wednesday, November 19, 2008
Scrum is Dead, Long Live Scrum
Hi,
"The king is dead, long live the king!"
People continue to be subject to the king even though the new king may be far less of a monarch than the previous one.
I recently attended the Scrum Gathering 2008 in Stockholm, Sweden.
It was great to see some of the old faces again and its great to recharge and re-energise by talking to like-minded "agilists".
The best day by far was the Tuesday when we did Open Space. This is when you're able to vote with your feet and be involved only in those topics you're interested in.
As a Scrum Practitioner I was able to both support people new to scrum, as well as talk to other practitioners and trainers about larger issues. These issues included integrating scrum within corporate governance models, contracts for agile methods and lean initiatives across companies outside the direct software development capability.
What was disappointing but not wholly unexpected, was the considerable shift from an informal gathering of like-minded people interested in learning and sharing scrum experiences, to a commercially-oriented, brand aware business conference.
The flagrant use of corporate presentations, and the "selling" of agile products and services by consultants and trainers alike really disappointed me. Obviously, there's now some real money to be made with agile and scrum and the bandwagon is super-charged.
Ultimately, Jeff Sutherland's joint corporate presentation promoting off-shore agile teams clearly showed to me that the old Scrum is dead. If the purity of a methodology cannot be maintained at its source, and promoted as the ideal, then those compromises will filter down and out across the board.
The message at the source of a methodology, which are the scrum gatherings, should be about the "ideal" and "pursuing perfection". The open spaces then become discussions about how to overcome obstacles preventing that goal through sharing experiences.
I'm hoping that other attendees provided similar feedback that reflected the frustration with corporate presentations and the need to revert to a more intimate, open space approach for the entirety of the next gathering.
I am however resigned to the fact that commercial gain will further dilute the real value of scrum until it becomes a shadow of its former self.
Scrum is Dead, Long Live Scrum!
"The king is dead, long live the king!"
People continue to be subject to the king even though the new king may be far less of a monarch than the previous one.
I recently attended the Scrum Gathering 2008 in Stockholm, Sweden.
It was great to see some of the old faces again and its great to recharge and re-energise by talking to like-minded "agilists".
The best day by far was the Tuesday when we did Open Space. This is when you're able to vote with your feet and be involved only in those topics you're interested in.
As a Scrum Practitioner I was able to both support people new to scrum, as well as talk to other practitioners and trainers about larger issues. These issues included integrating scrum within corporate governance models, contracts for agile methods and lean initiatives across companies outside the direct software development capability.
What was disappointing but not wholly unexpected, was the considerable shift from an informal gathering of like-minded people interested in learning and sharing scrum experiences, to a commercially-oriented, brand aware business conference.
The flagrant use of corporate presentations, and the "selling" of agile products and services by consultants and trainers alike really disappointed me. Obviously, there's now some real money to be made with agile and scrum and the bandwagon is super-charged.
Ultimately, Jeff Sutherland's joint corporate presentation promoting off-shore agile teams clearly showed to me that the old Scrum is dead. If the purity of a methodology cannot be maintained at its source, and promoted as the ideal, then those compromises will filter down and out across the board.
The message at the source of a methodology, which are the scrum gatherings, should be about the "ideal" and "pursuing perfection". The open spaces then become discussions about how to overcome obstacles preventing that goal through sharing experiences.
I'm hoping that other attendees provided similar feedback that reflected the frustration with corporate presentations and the need to revert to a more intimate, open space approach for the entirety of the next gathering.
I am however resigned to the fact that commercial gain will further dilute the real value of scrum until it becomes a shadow of its former self.
Scrum is Dead, Long Live Scrum!
Tuesday, June 24, 2008
Fearless Change
I've recently joined T-Mobile as Agile & Online Programme Manager, and although there is an appetite in localised areas for agile adoption, there are some more fundamental areas of change required before real progress can be quantified.
Corporate IT strategy, budget governance, resource models, enterprise architecture and software development all need to change and require long-term commitment. Shifting towards agile concepts, mindsets, methods and practices is a significant undertaking and clearly, Toyota's statement of 12 years to "lean" is not only true, but probably an understatement.
Over the last few years software developers have often proselyted the use of software patterns, and having read around Alexander's original architectural patterns, I've become a user of organisational patterns.
The core, unique benefit of pattern theory is that it is the codifying of experience. This isn't some individual's idea of how to do something; patterns are derived from actual experiences of a problem context, the solutions that were applied, and that have worked before... Many times.
I've previously blogged about Coplien's book on Organisational patterns of Agile software development, but I've been using change patterns from a book called Fearless Change.
These patterns codify key lessons learnt by people who have tried to introduce innovation within corporate entities. This is not just about introducing agile, but about any innovation, and the benefit to anyone new to change management is that there are tried and tested patterns available.
Key roles identified include the maven, salesman and connector. Patterns I've used and that are bearing fruit include Evangelist, Do Food, Just Do It, Test the Waters, Small Successes, Time for Reflection, Step By Step, Plant the Seeds, E-forum and Brown Bag.
The other benefit of using this book as a tool, is that it is supportive to people in the midst of the struggle to introduce change and innovation. Others have been where you are now, and this is how they succeeded!
If you are not aware of, or using, a facet of pattern theory, you're missing a trick!
Corporate IT strategy, budget governance, resource models, enterprise architecture and software development all need to change and require long-term commitment. Shifting towards agile concepts, mindsets, methods and practices is a significant undertaking and clearly, Toyota's statement of 12 years to "lean" is not only true, but probably an understatement.
Over the last few years software developers have often proselyted the use of software patterns, and having read around Alexander's original architectural patterns, I've become a user of organisational patterns.
The core, unique benefit of pattern theory is that it is the codifying of experience. This isn't some individual's idea of how to do something; patterns are derived from actual experiences of a problem context, the solutions that were applied, and that have worked before... Many times.
I've previously blogged about Coplien's book on Organisational patterns of Agile software development, but I've been using change patterns from a book called Fearless Change.
These patterns codify key lessons learnt by people who have tried to introduce innovation within corporate entities. This is not just about introducing agile, but about any innovation, and the benefit to anyone new to change management is that there are tried and tested patterns available.
Key roles identified include the maven, salesman and connector. Patterns I've used and that are bearing fruit include Evangelist, Do Food, Just Do It, Test the Waters, Small Successes, Time for Reflection, Step By Step, Plant the Seeds, E-forum and Brown Bag.
The other benefit of using this book as a tool, is that it is supportive to people in the midst of the struggle to introduce change and innovation. Others have been where you are now, and this is how they succeeded!
If you are not aware of, or using, a facet of pattern theory, you're missing a trick!
Wednesday, March 19, 2008
Agile Leaders - The Next Hurdle
So you know what Scrum, XP & Agile are all about, got the T-shirt etc.
You're fine tuning scrum practices in your company.
You're running multiple scrum teams, you've adopted most of the XP practices, (test driven development taking a while?).
Agile approaches are spreading across your company's project portfolio.
You've even achieved the holy grail and have board level support!
What's next?
Where do you focus your long-term thoughts?
How do you get the entire company behind you?
How do you create an Agile Business?
What does your next learning curve look like?
How do you achieve more?
Answer: Lean Thinking & Financial Understanding
Too boring?
Who'd have thought that there are a simple set of principles, that when correctly applied, rapidly improve any business in any sector of industry. And, when applied to other departments and functions within your business, will enhance and improve your own project team's output.
Have a good look at your previous impediments. Which took the longest to overcome? Were the long-standing ones due to outside influences?
Is your procurement process too slow?
Infrastructure teams inflexible?
Funds not available?
Training budgets restricted?
Lean Thinking is the best approach to achieving "Agile" levels of performance across the business. And the easy part is getting started.
Lean starts with Eliminating Waste, and from my experience the identification and elimination of the 7 types of waste leads to immediate cost savings directly visible on the bottom line.
This is something the board will understand immediately!
Every single business regardless of sector has waste, and with some thought and application you can "Learn to See"the waste in your business and start removing it.
I recently completed a value chain analysis which has identified savings of over £250,000 per annum. The project to implement the changes began this week.
This isn't rocket science, but it does need you to step out of the comfort zone. You do need to analyse and understand your budgets, performance, and processes. My time with Shaun Mundy at CPM showed me the value of this.
It's alright being bloody great at Agile, and knowing how to deliver software and create self-organising teams, but always remember that the engine for change, the real way to effect change, is control of the P&L.
Agile leaders need to understand and learn to speak the language of the P&L, balance sheet and cashflow if widespread corporate level change is to be accomplished.
Couple financial understanding with lean implementation and Agile leaders will be building not only successful agile project teams, but successful agile companies.
So, go on, nip down to your accounts department today and ask for last month's P&L.
I dare you!
Mary Poppendieck is "Yoda" on this subject - http://www.poppendieck.com/
http://www.lean.org/
You're fine tuning scrum practices in your company.
You're running multiple scrum teams, you've adopted most of the XP practices, (test driven development taking a while?).
Agile approaches are spreading across your company's project portfolio.
You've even achieved the holy grail and have board level support!
What's next?
Where do you focus your long-term thoughts?
How do you get the entire company behind you?
How do you create an Agile Business?
What does your next learning curve look like?
How do you achieve more?
Answer: Lean Thinking & Financial Understanding
Too boring?
Who'd have thought that there are a simple set of principles, that when correctly applied, rapidly improve any business in any sector of industry. And, when applied to other departments and functions within your business, will enhance and improve your own project team's output.
Have a good look at your previous impediments. Which took the longest to overcome? Were the long-standing ones due to outside influences?
Is your procurement process too slow?
Infrastructure teams inflexible?
Funds not available?
Training budgets restricted?
Lean Thinking is the best approach to achieving "Agile" levels of performance across the business. And the easy part is getting started.
Lean starts with Eliminating Waste, and from my experience the identification and elimination of the 7 types of waste leads to immediate cost savings directly visible on the bottom line.
This is something the board will understand immediately!
Every single business regardless of sector has waste, and with some thought and application you can "Learn to See"the waste in your business and start removing it.
I recently completed a value chain analysis which has identified savings of over £250,000 per annum. The project to implement the changes began this week.
This isn't rocket science, but it does need you to step out of the comfort zone. You do need to analyse and understand your budgets, performance, and processes. My time with Shaun Mundy at CPM showed me the value of this.
It's alright being bloody great at Agile, and knowing how to deliver software and create self-organising teams, but always remember that the engine for change, the real way to effect change, is control of the P&L.
Agile leaders need to understand and learn to speak the language of the P&L, balance sheet and cashflow if widespread corporate level change is to be accomplished.
Couple financial understanding with lean implementation and Agile leaders will be building not only successful agile project teams, but successful agile companies.
So, go on, nip down to your accounts department today and ask for last month's P&L.
I dare you!
Mary Poppendieck is "Yoda" on this subject - http://www.poppendieck.com/
http://www.lean.org/
Monday, March 12, 2007
Inversion Management - 21st Century Leadership
Using the term "Management" in the title of this blog, reflects part of the problem with the dominant logic of mainstream business.
I've been with TV Network for just over a year now, and its been exciting, frustrating, inspiring, draining, hard work and fun!
Establishing an agile project, running an agile programme, creating an agile department, evolving an agile company... each level requires new skills, different perspectives, perseverance and openness to change.
Your perspectives change, you change...
I believe the most successful business leaders today are shifting through an Inversion of Leadership.
The inherited perception and mindset of management, is one of hierarchy, command & control, transactional leadership, management by exception, reward & recognition, sequential projects and long-term strategic planning.
Agile leaders believe in flat structures for real-time communication, encourage delegation and de-centralisation of control, exude transformational leadership, are naturally inclusive decision makers, care about Corporate Social Responsibility, adopt iterative processes, create vision, define objectives and are continuous change agents.
Agile leaders exist as a minority not only in software development, but in all industries.
The mainstream, pervading approach to "management" is based on reward and recognition, direction and control.
The emerging approach, for successful companies, will be leadership and vision, delegation and inspiration, training and mentoring, support and coaching.
From my experience it is much harder to be a leader, coach, delegate and mentor when there are deadlines, profit/loss and long hours to deal with... but at the same time you can achieve a hell of a lot more.
Do I think Inversion Management will replace mainstream practices?
Will agile leaders be wanted across business?
Not until the current mindset of shareholders, the stock market and banking institutions of looking at quarterly profit margins, and quick revenues, shifts to being concerned about sustainable business, sustainable wealth, and the ability of companies to change and innovate.
I've been with TV Network for just over a year now, and its been exciting, frustrating, inspiring, draining, hard work and fun!
Establishing an agile project, running an agile programme, creating an agile department, evolving an agile company... each level requires new skills, different perspectives, perseverance and openness to change.
Your perspectives change, you change...
I believe the most successful business leaders today are shifting through an Inversion of Leadership.
The inherited perception and mindset of management, is one of hierarchy, command & control, transactional leadership, management by exception, reward & recognition, sequential projects and long-term strategic planning.
Agile leaders believe in flat structures for real-time communication, encourage delegation and de-centralisation of control, exude transformational leadership, are naturally inclusive decision makers, care about Corporate Social Responsibility, adopt iterative processes, create vision, define objectives and are continuous change agents.
Agile leaders exist as a minority not only in software development, but in all industries.
The mainstream, pervading approach to "management" is based on reward and recognition, direction and control.
The emerging approach, for successful companies, will be leadership and vision, delegation and inspiration, training and mentoring, support and coaching.
From my experience it is much harder to be a leader, coach, delegate and mentor when there are deadlines, profit/loss and long hours to deal with... but at the same time you can achieve a hell of a lot more.
Do I think Inversion Management will replace mainstream practices?
Will agile leaders be wanted across business?
Not until the current mindset of shareholders, the stock market and banking institutions of looking at quarterly profit margins, and quick revenues, shifts to being concerned about sustainable business, sustainable wealth, and the ability of companies to change and innovate.
Thursday, March 08, 2007
"Agile" or "agile"
If, like me you seek insights into how to really create "Agile" businesses, I'm afraid there's a mountain of hype, miscommunication and misunderstanding to wade through.
"Agile" has over the last 2 years become the latest "fad" in business circles (certainly I.T. circles) and so of course, every Tom, Dick and Harry is jumping on the bandwagon trying to make a "buck!"
I attended a Scrum Gathering in the States about 2 years ago when the issue of how to rapidly implement Agile across large organisations was a key topic. The truth is, that as with anything in life, it takes time, alot of time, to get something worth having!
Toyota are quoted as saying it takes 12 years for a corporation to become lean, and I believe them.
"Agile" with a capital A, is not just about adopting a methodology or some SOA or web services architecture; Agile is about shifting executive, middle management and "coal-face" employee mindsets from heirarchical, document-heavy, linear thinking to creating an organisational culture that embodies the tenets of the agile manifesto:
To really value collaboration over contracts, the individual over processes and systems, and value responding to change, over long-term planning.
This is Agile with a capital A, and a true understanding of Agile can only be achieved by pioneering it within your own sphere of influence and experiencing it for yourself. If you want help getting started see Womack, Jones, Poppendieck and Schwaber for reference.
Any company, person, or software architecture can claim to be agile, but, to cut through the hype you need to find those people who know the difference...
"Agile" with the capital 'A', or "agile" with a small 'a'.
"Agile" has over the last 2 years become the latest "fad" in business circles (certainly I.T. circles) and so of course, every Tom, Dick and Harry is jumping on the bandwagon trying to make a "buck!"
I attended a Scrum Gathering in the States about 2 years ago when the issue of how to rapidly implement Agile across large organisations was a key topic. The truth is, that as with anything in life, it takes time, alot of time, to get something worth having!
Toyota are quoted as saying it takes 12 years for a corporation to become lean, and I believe them.
"Agile" with a capital A, is not just about adopting a methodology or some SOA or web services architecture; Agile is about shifting executive, middle management and "coal-face" employee mindsets from heirarchical, document-heavy, linear thinking to creating an organisational culture that embodies the tenets of the agile manifesto:
To really value collaboration over contracts, the individual over processes and systems, and value responding to change, over long-term planning.
This is Agile with a capital A, and a true understanding of Agile can only be achieved by pioneering it within your own sphere of influence and experiencing it for yourself. If you want help getting started see Womack, Jones, Poppendieck and Schwaber for reference.
Any company, person, or software architecture can claim to be agile, but, to cut through the hype you need to find those people who know the difference...
"Agile" with the capital 'A', or "agile" with a small 'a'.
Subscribe to:
Posts (Atom)
Posts
