Posts Tagged ‘lean’

Agile and Lean in Construction

Tuesday, December 20th, 2011

Author: Dr. Adrian Smith, Ennova

Large scale construction projects suffer from cost and time overruns that are typically a symptom of productivity problems and directly affect overall industry profitability. As a result, methodologies have been developed to reduce the risk of overruns and improve project outcomes.

A number of these methods are based upon Lean principles that focus on identifying value, eliminating waste and creating a smooth flow of materials, information and work.

Construction Productivity:
Studies [1] suggest that between 70% and 90% of projects exceed the original planned cost and that the overrun commonly varies between 50% and 100% of budget. Some well known examples of significant project overruns include:

  • Sydney Opera House – Final cost was 15 times more than originally planned
  • Channel Tunnel – Final cost was 80% more than originally planned
  • Boston Arterial Tunnel – Final cost was 196% more than originally planned

(more…)

Safe to fail – Blame worthy or Praise worthy?

Friday, August 19th, 2011

Author: Phil Abernathy

In the April 2011 issue of the Harvard Business review , Amy Edmonson , Professor of Leadership and Management at the Harvard Business review, has a great article on strategies for learning from failure.

It made me think of  how the Agile way of working looks at failure and how we learn from it . In Agile the ‘safe to fail’ mantra is often talked about and just as often abused in more ways than one.

Sometimes teams and people are blamed for failure and hence don’t feel safe, sometimes teams use the ‘safe to fail’ umbrella to not follow any procedure or agreed rules and just do what they want.

A ‘safe’ environment is essential for improvement and innovation, creativity and morale, the key ingredient to creativity and morale, the key ingredient to creating this safe environment is clarity of what types of failures are ‘safe’.

The Failure Spectrum

 

 

(more…)

Agile is a Fad!

Monday, July 18th, 2011
 
Author:  Jonathan ‘Kupe’ Kupersmith
 

Jonathan 'Kupe' Kupersmith

Jonathan “Kupe” Kupersmith is Vice President of Brand Development, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at kupe@b2ttraining.com.
 
(This blog was originally written on the BA Times blog site. It is kindly reproduced here with Kupe’s permission).
 
Agile is the hottest word in our profession these days. Go to any BA or PM conference and there is at least 1 session dedicated to agile. Even if the session does not have agile in it, you’ll hear the agile word over and over. On sites like this one, there are many blogs and articles written about agile. Here is the article that inspired me to write this post, Four Agile Tips to Eliminate Rework in Application Development.
 
 The article lists these four tips which are credited to agile methods.
  1. Collaborate – Involve multiple stakeholders in requirements definition.
  2. Be Lean – Quote from article – “Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.”
  3. Iterate – Approach requirements definition in an iterative process.
  4. Visualize – requirements do not have to be written in paragraph form.

I agree 100% with all of these tips not because they are agile tips, but because they are smart practices. Before the Agile Manifesto was developed, I worked on teams that collaborated, were lean, iterated, and visualized. I wrote about this in a blog post last year, My First Agile Project. I would guess you have been doing this for some time too. This is why the word agile is a fad. In the near future we will stop having debates of whether you use agile vs. traditional approaches. We’ll just start doing what is appropriate for projects to drive results.

This spring I saw Scott Ambler speak and he said we don’t need repeatable processes we need repeatable results. What this says to me, is do what is needed to drive results.  Teams need to come together and determine what will work best to give them the best chance to deliver results. This is just smart.

The agile movement shook our community and made us all think about how we were running projects. It made us make sure we are focusing on business value. Don’t push for agile over waterfall, push for what is right for the project. Push for what is right for the business in the short and long term. Even though I think the word agile is a fad, the agile movement is definitely a trend.

All the best,

Kupe

Don’t forget to leave your comments below.

Be Lean by keeping words to a minimum!

Monday, April 18th, 2011

Author: Susan Akers

Imagine if we limited speakers to 20 seconds per Powerpoint slide for a total of 20 slides – yes – a total of 6 minutes and 42 seconds.
(more…)

Becoming Agile

Sunday, December 19th, 2010

Author: Craig Smith

After a recent talk I gave about Being a Business Analyst in an Agile world, I was asked for some resources that might also help a Project Manager move into the world of Agile. The difficult thing I find that project managers deal with on Agile teams is the need to let go of work at the task level, and the need to move to more of a leader role and what I call a “traffic cop” that protects the team.

The PM is outside the core team, dealing with stakeholders, budgets, resourcing and all of the big issues whilst protecting the team so they can get on and deliver software. Hence the reason I recommend that a PM is not the iteration now.

For Leadership and Project Management:

And then there are many new leadership techniques which fit hand in hand with Agile (moving from management to leadership) as well as many good books, but a couple to get you started:

Some great books:

Here is a list that was put together earlier in the year of the Top 100 Agile books, and I would agree with most of the titles on this list, so it might be worth a browse as well.

Agile Training:

Finally, it would be remiss of me not to mention the Agile Academy, they have a two day Project Management course that was developed originally based on work carried out in Suncorp.

Craig is an Agile coach and has spoken at various conferences about Agile and related topics including Agile 2010, Agile Australia 2010 and the Atlassian Summit. He openly shares his knowledge and experiences through slideshare and his blog.

When does cutting the fat go beyond Lean?

Monday, December 6th, 2010

Author: Susan Akers

I have been working on our continous improvement program lately as I think trying to make your processes more Lean is a great idea and that just because they are working it doesn’t mean that circumstances haven’t changed so they could be made better. But this thought also struck me – Can you go too far when trying to make your processes or projects Lean?


Reviewing a printing and data storage process recently to ensure that we had only one centre of truth and to also remove a blocker, we were able to cut 5 steps immediately from the process reducing our risk dramatically.

However, with the feeling of joy that followed it was very tempting to keep doing. Luckily common sense prevailed.

I just wondered if other people had seen this happen where people have jumped on the Lean bandwagon and gone too far?

“Is artificial velocity spoiling your team?”

Wednesday, August 18th, 2010

Authors: Ryan McKergow and Daniel Ginn

Artificial velocity is the velocity achieved when an agile team is not working sustainably. After recent discussions, the two of us decided to adopt the term to describe the dangerous precedents and practices that it sets. Artificial velocity can affect an Agile team in a number of ways, by reducing morale, and losing focus and creativity. Some examples of behaviour that promotes artificial velocity, include working long hours to finish a vastly underestimated story, or not realigning expected velocity when reality is not reflected.

Reduced Morale
One of the results of artificial velocity is reduced morale, which can come in many forms including: workaholics, old-school management styles (such as McGregor’s Theory X), and comparing yourself unrealistically to your colleagues.

For example if two kids are asked to mow the lawn, one sits down for 5 mins to work out whether going back and forth or going around in ever smaller circuits is quicker, and then finishes 15 mins before the kid who jumped straight in, is he lazy cause he’s now watching TV? No, he worked smarter. He’s achieved the same outcome in less time, meaning he has more time to do what he wants to do. People jump to conclusions when they look at the boy who is now relaxing. They assume he is being lazy, but he’s actually done the job much more efficiently.

We believe this is a result of misconceptions stemming from old school management techniques, thinking that the work we do in an office can somehow be related to the hours spent on the production line. In the office environment where a lot of our work involves cognitive thinking instead of brute force, there is a much bigger variance. Because of this mind set, some people try to emulate workaholics to “impress” the boss. This can lead to a loss of focus and creativity, because everyone is trying to look busy, as opposed to actually doing useful work.

Lost Focus and Creativity
We also believe it’s important to recognise the power of a fresh and focused mind. Tired minds are more likely to make or overlook mistakes which will put yet more pressure on the time it takes to complete a Story, or heaven forbid adding to the Tech Debt. You don’t need to continually wear yourself out by staying back late or losing sleep, honestly, are you really going to get much work done past 5pm? And if you think you are, where did you get the energy to do this, if you were working “hard” for the rest of the day? We need rest and time to relax. And it’s when we are relaxed when we are most likely to be hit with inspired ideas. So other than having a good night’s sleep, what are some practical ways at work to avoid artificial velocity?

So what can be done?
First off, believe in Agile! Agile provides some excellent practices that encourage the right behaviour, however, we would like to focus on a few established practices and a new one that might help avoid artificial velocity:

  1. Social contracts – These might be one of the greatest Agile tools with respect to avoiding artificial velocity. Incorporating expectations around what is and what is not acceptable behaviour in terms of supporting sustainable development is what is needed. Identifying instances where a different approach to a task resulted in a story point saving and sharing it with the team should be codified.
  2. Points bank – Another possible behaviour driving device might be the story point bank. A team member can ‘bank points’ when they can show that a smarter approach resulted in a point saving. Using a Big Visual Chart that team member can be recognised for the point saving. As an option the IM could spend the saved points by letting team members go early, or allow time to work on something different (Google time). In addition to this, the time saving approaches would be great to be fed into retrospectives.
  3. Working smarter – Setting the right expectations, not just for the core project team, but for everyone involved in the project (including upper management, and our project sponsors), should be equally encouraged. As Agile welcomes changes to the software or product, we need to be equally welcome to change in expectations on the project team. This requires you to be open and honest, even if it can be difficult. If an 8 point card turns out to be an epic, is it still reasonable to maintain the same expectations of time, cost and quality? We think not! You should revaluate the card and then revaluate the expected velocity for this iteration.
  4. Conclusion
    Artificial velocity is misleading to all. It places unnecessary pressure on the team, sets unrealistic expectations for the customers and reduces the creativity of individuals. So we would like to put it back to the reader, what do you think about artificial velocity?

    Inspired by

  1. The Creativity Formula, Dr Amantha Imber ISBN-13: 978-0646509624
  2. Rework, Jason Fried & David Heinemeier Hansson ISBN-13: 978-0307463746

Agile – Beyond Scrum!

Tuesday, April 27th, 2010

Author: Stephen Lawrence, CSM, CSP, PMP, Agile PM Masterclass

As a practising and Certified Scrum Practitioner and ScrumMaster I see tremendous value in the tools and techniques Scrum has given the project world. I also acknowledge that there are more tools and techniques outside of Scrum which can further enhance the value delivered to stakeholders and improve the chances of a successful project.

One example is the use of a concept phase & planning workshops to capture the following essential data is just one example of techniques and tools not taught in Scrum – but vital to understanding your stakeholders needs.

  • Objectives and outcomes a project is to deliver and what changes are necessary to achieve this.
  • What are the trade-off criteria the sponsor and key stakeholders are prepared to move on to ensure a successful delivery?
  • What are the key business benefits the business wishes to achieve?
  • What are the high level features prioritised that will deliver the outcomes – think People process and technology to ensure the objectives and outcomes are achieved – not just a technical solution.

These are all essential Agile tools outside the Scrum toolkit but add significant value to an Agile project. (Thanks Rob Thomsett for these wonderful tools. I highly recommend reading Rob’s “Radical Project Management” for more great ideas and concepts). Another way to add to your toolkit would also be to go to an Agile Academy course to learn how to use these and other tools.

Nor am I a member of the Scrum fraternity advocating the demise of Project Managers. In fact, I am passionately the opposite; I fully endorse the need for PMs but they need to adapt to an Agile world.
Command and control is dead – facilitation and leadership skills are now to the fore!

So the big question is:

How do you empower teams while ensuring accountability, responsibility, openness and transparency?

Unfortunately not all PMs or indeed managers can make this change, nor can all people in a team self-manage. It is an interesting dilemma and one most teams will face at some time. However, to be successful it is important that this issue is acknowledged and addressed. SUCCESSFUL AGILE IS A WHOLE OF TEAM APPROACH – NOT INDIVIDUALS.

Other frameworks such as Feature Driven Development (FDD), eXtreme Programming (XP), Dynamic Systems Development Model (DSDM)(Atern), Crystal, Lean etc. can also add real value to an Agile world. Agile is a framework underpinned by values, processes with a number of tools and techniques that can be used and adapted to best fit.

Feel free to pick and choose not be constrained by dogma. Your stakeholders and sponsor are your customers and you need to ensure you deliver a solution that meets their expectations and achieves the project’s objectives and outcomes.

Scrum is an excellent place to start but don’t let your journey end there.