The 7 Software Development Wastes - Lean series Part 5 - Motion

The 7 Software Development Wastes - Lean series Part 5 - Motion

Introduction

Previous posts on software development wastes can be found here: In-Process Inventory/Partially done work , Over Production/Extra Features , Extra Processing and Transportation

I must apologize to you all for the lag in this series. But being August, I was away on vacation. Interestingly, getting back is hard. You have to get back into the swing of things again to get up to maximum productivity. There's quite a bit of re-acquainting and relearning so there's waste for sure. However, I do feel I have more energy now since I am back so perhaps the waste is negated over time.

Motion - Task Switching

Waste #5 in manufacturing is defined as Motion. And motion can be compared to "task switching" in Software Development - as defined by the thought leaders applying Lean thinking to software development.



Task switching can be a big time waster. Studies have shown that if you're working on anything beyond two seperate and distinct tasks, your efficiency goes down drastically the more tasks you take on. The reason is quite obvious; working on software development tasks takes a lot of thought processing and task switching requires that your mind switch contexts all the time. Each time that you switch contexts, there's relearning and re-acquainting that needs to take place.

Additionally, if you are working on multiple tasks simultaneously, it's going to take you longer to complete the first and each successive tasks. If you storm the first task and get that out, you are delivering value to the customer much sooner.

It's important to be mindful of this. I have found in many organizations, especially software companies where there is a real casual atmosphere, it's easy to always interrupt developers. Interruptions are prevalent with requests. All this interruption only serves to add to the Motion bucket of waste. This is where the importance of a Product Owner, ScrumMaster and Backlog come in. These roles and any artifact are there to buffer the development teams from the noise and chaos outside of the current sprint activities.

What Makes a Successful Agile Coach?

What Makes a Successful Agile Coach?

People often ask me "how does Agile tell you to do " and having recently presented the fundamentals of Agile to a large mix of people, the textbook answer is "well, it depends". Folks who have little to no experience with Agile seem to be much more accepting of the fact that "being Agile" is all about taking the tools, knowledge and frameworks and applying them to your situation. Some though Agile was a software tool, chaotic and very confusing. They are actually very relieved to see the benefits that adopting Agile methods bring. I stress that it's more about becoming a learning organization and that Agile adoption is about culture first and foremost.

Experiment. Fail. Learn, move on and get better next time around. That is what "being Agile" is all about.

There is no magic formula or checklist to makes an Agile adoption successful. It's up to how willing the individuals are to accept help from a coach or how open they are to getting out of their comfort zone to improve on something that isn't working. Class after class I get bombarded with questions that range from how QA integrates with an Agile team to "how does Agile tell you to deal with the expense of buying a developer a laptop?". (yes, that was a REAL question I was asked once).

Esther Derby posted a few months ago about 5 reasons to hire an Agile Coach which leads me to ask what actually makes a coach successful? What makes a coach worthy of self-labeling himself a coach in the first place? These are the top 3 attributes I consider to be the most important:

1) Self-less: A coach must care about the team (and organization) and morally and ethically do what is right. A good coach must possess the desire to work their way out of a job for the greater good of the organization that has invested time, money and most importantly trust in the coach's abilities. Now in the real world I am quite sure there are some folks who want to extend the gig as long as possible for security or other selfish reasons, but IMO that's not the point. If you are trying to teach and organization how to build trust, that lesson starts with the coach.

2) Honesty: A good coach must be clear that the road may (and mostly likely will) get rough and there is a chance adopting Agile just will not work if the organization doesn't want to change. You can say "honesty is the best policy" is a rally-cry or fluffy sounding but it rings true. If you set the expectation that you will be honest regardless of how painful that honesty may be sometimes, a coach will stand to earn the respect and trust ...

An Introduction to Lean for Agile Managers

http://agile101.net/2009/08/14/an-introduction-to-lean-for-agile-managers/

Diana Larsen, chair of the Agile Alliance, delivers a really informative, and easy-to-follow seminar on the subject of Lean for Agile Managers. In this seminar, Diana explains the origins of Lean, elaborates upon the seven core Principles of Lean and offers insight into ways to maximise value and reduce waste.

Diana also touches on the following topics/questions:

• How do Managers fit into the Value Streamand how can you reduce Management waste?
• How do we focus our work in a Lean environment?
• What is ‘Tracking and Fanning’? (i.e. find what works and do more of it!)
• Minimising/Reducing your ‘Zone of Disturbance’
• What is an ‘Agile Heartbeat’?
• The importance of ‘Navigating the Team Boundaries’
• The importance of gaining support from the organisation
• The importance of celebrating both small and large successes
• Encouraging change in the systems that undermine the team

The Seven Principles of Lean

1. Eliminate waste
2. Amplify learning (organisational and individual)
3. Decide at the last *responsible* moment (keep your options open)
4. Deliver as fast as *possible* (without compromising value)
5. Empower the team (”every decision needs to be made closest to where the work is done”)
6. Build integrity into the system
7. See the whole (”think in terms of the whole system not local optimisation”)

A Lean Glossary

• Customers = people who USE your products
• Flow = maximising the movement of work through the process
• Gemba = the place where the work is ‘done’
• Kaizan = continuous improvement (e.g. retrospectives)
• Kaikaku = radical improvements (e.g.
• Kanban = the pull system
• Muda = waste
• Perfection = the continuous quest for value and reduction of waste
• Value = as defined by the customer (ONLY the customer can say what value is)
• Value Stream = the critical chain of work process steps we go through to deliver value to the customer (each step must deliver value)

The road map to success

http://strangemaps.wordpress.com/2009/08/12/406-caruso-cant-touch-you-a-road-map-to-success/

The Product Manager – Role and Responsibilities

http://agile101.net/2009/08/07/the-product-manager-role-responsibilities/?utm_source=rss&utm_medium=rss&utm_campaign=the-product-manager-role-responsibilities

Convert Google Reader Items to PDFs [Google Reader]

Convert Google Reader Items to PDFs [Google Reader]: "

Once Google Reader added manual controls to its new 'Send To' menu, you knew some delicious URL tweaks would follow. Some already have, including a 'Save as PDF' trick from the Digital Inspiration blog.

If you want to save a Reader feed item as a PDF, email a full blog post to somebody when you only see a partial item, or work more intelligently with social services, Amit Agarwal has your hook-up. Head to Settings in Reader, click the 'Send To' tab, then hit 'Create Custom Link' at the bottom. You'll be asked for a Send To link name, a URL with replacement codes, and an icon location. The link below has all three of those for its tweaks, including one that creatively uses the previously mentioned PDF Online converter.

We are, of course, open to your own suggestions and codes that extend Google Reader through this neat little open door. Share the links and URLs in the comments, and we'll possibly pick them up for a meatier post down the line.

Download Your Google Reader Stories as PDF & other 'Send To' Hacks [Digital Inspiration]

Leading Agile... the Book?

Leading Agile... the Book?: "I have some pretty exciting news... both for me...and hopefully for the regular readers of Leading Agile. A few months ago, Dennis Stevens and I pitched and idea for a book to Addison-Wesley. Well... today we hit the jackpot... we got a contract. The book is tentatively titled 'Rethinking the Agile Enterprise' and... like the Cutter paper... covers much of the material I talk about on this blog.

What's the one-line pitch?

This book lays out a lean strategy… and an actionable framework… for organizing teams, projects, and programs for successful enterprise software delivery

What's the book about?

This book marries three core concepts into an actionable guide for building an adaptive organization. First… the book asserts that adaptive organizations are built around teams. We explain how to form teams… why teams work… and how agile and lean concepts can help managers establish high performing teams. Second… we explain how teams work together to deliver against the larger goals of the organization. This gets into lean project management, program management, and portfolio management. Lastly… we discuss a specific tool called capability modeling that helps organizations decide where to focus their energy to get the greatest return on their investment.

Why is it Important?

Companies are interested in becoming more adaptive… more agile… not because they have an interest in Scrum or XP… but because they are trying to deliver value to market faster than their competition. Most of the current agile literature does not address the real problems facing complex organizations. The literature assumes everyone is organized around small cross functional teams that build software features. Many of these books advocate transition strategies that are not practical for the enterprise and cannot be implemented at scale. The market needs a book that meets business leaders where they are… and helps them get to where they need to be. We are advocating a targeted and disciplined approach to becoming more agile across the entire enterprise.

Why will anyone care?

Business leaders are trying to implement agile methodologies but are not fully aware that their underlying organizational structure is negatively impacting their ability to change. This book provides a starting place for sorting through the complex set of decisions required to implement widespread organizational change. Mike and Dennis explain the strategies… principles… and tactics required to systematically build a more adaptive enterprise.

How you can help

Clearly... clearly... over the next year... Dennis and I will be blogging around the topics we are writing about. Please give us your feedback and share your ideas for making the book better. As chapters are ready... we'll need reviewers. When we get that far... I'll reach out to you guys for your help.

This is going to be quite an adventure and a REALLY, REALLY busy 15 months!

Mike
http://www.leadingagile.com

Agile Project Management: Risk Management

Agile Project Management: Risk Management: "This is a guest blog post from Tara Whitaker. Tara has recently launched a new agile blog called Agile 101.

It really is amazing how much content Tara has already published on agile project management and agile programme management.

Here's a taster...

A Risk is an uncertain event that will impact your chosen path should it be realised. Risks are events that are not currently affecting you - they haven't happened yet. Once a risk is realised, it has the potential to become an Issue(s).

The following activities are more traditionally carried out by a Project Manager. In Agile working environments, the responsibility for risk management is shared by all involved.

• Identify a risk


• Assess a risk


• Respond to a risk


• Reviewing risks

The old saying 'a problem shared is a problem halved' comes to mind. In Agile Software Development environments, we accept that projects are ridden with complexity and uncertainty.

By promoting communication, distributing the responsibility of risk identification/mitigation and enabling ourselves to respond quickly to change, we are fundamentally better equipt to dealing with Risk than more traditional environments.

With that said, there don't seem to be any official guidelines on how to manage risks within an Agile environment, so I'll combine my personal views with notes and ideas I've found scattered around the web.

The articles below provide an overview of Risk Management within an Agile context and take you through the four key stages of the Agile Risk Management Lifecycle:

• Agile Risk Management – Risk Identification (Step 1 of 4)


• Agile Risk Management – Assessing Risks (Step 2 of 4)


• Agile Risk Management – Risk Response (Step 3 of 4)


• Agile Risk Management – Risk Review (Step 4 of 4)


• Agile Risk Management – The difference between Risks and Issues


• 12 Principles of Risk Management (PMBOK - with an Agile slant)

Enjoy!

Tara.

"

Google Code Jam is back!

Essayez donc de vous pratiquer avec les examens des années passées ;-)

http://code.google.com/codejam/contest

Song: Being Agile is our favourite thing

Google Opt Out Feature Lets Users Protect Privacy By Moving To Remote Village

Google Opt Out Feature Lets Users Protect Privacy By Moving To Remote Village

Geek Stuff: Scratching

Motorola S9-HD Bluetooth Stereo Headphones for iPhone 3G/3GS

http://iphonefreakz.com/2009/08/11/motorola-s9-hd-bluetooth-stereo-headphones-for-iphone-3gs/

Références CSS3 et HTML5

Références CSS3 et HTML5 en PDF en français

Lean and Kanban Software Development Digest

http://www.targetprocess.com/blog/2009/05/lean-and-kanban-software-development.html

Agile Manifesto

http://www.agilemanifesto.org/

Pair Programming Primer

http://www.betterprojects.net/2009/08/pair-programming-primer.html

Prioritising for Profit – Creating and Prioritising Product Backlogs

http://agile101.net/2009/08/10/prioritising-for-profit-creating-and-prioritising-product-backlogs/