Project Management

Agility and Project Leadership

by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility

Categories

Date

Agile is starting to get pretty personal

linkedin twitter facebook Request to reuse this  

As much as I try to keep up with and write about trends in Agile project management, I always seem to learn something new!  Though the trend of applying Agile for personal productivity is nothing new, the fact that there are two published books on this topic is new to me.  Here's a couple of good books that may be worth you while if you are interested in applying Agile for your personal productivity initiatives.  The first is titled Personal Kanban: Mapping Work | Navigating Life by Jim Benson:

 
As the books blub outlines: 
 
Personal Kanban asks only that we visualize our work and limit our work-in-progress. Visualizing work allows us to transform our conceptual and threatening workload into an actionable, context-sensitive flow. Limiting our work-in-progress helps us complete what we start and understand the value of our choices. Combined, these two simple acts encourage us to improve the way we work and the way we make choices to balance our personal, professional, and social lives. Neither a prescription nor a plan, Personal Kanban provides a light, actionable, achievable framework for understanding our work and its context. This book describes why students, parents, business leaders, major corporations, and world governments all see immediate results with Personal Kanban.
 
Another book with a similar bent, but looking at the application of Lean overall for personal productivity is A Factory of One: Applying Lean Principles to Banish Waste and Improve Your Personal Performance by Dan Markovitz:
 
 
This book's blub outlines the book's content as follows:
 
A Factory of One: Applying Lean Principles to Banish Waste and Improve Your Personal Performance describes how you can foster a new mindset and improve your performance by applying Lean methods to your work. It translates powerful Lean tools such as visual management, flow, pull, 5S, and kaizen to your daily work, revealing how they can help to improve efficiency, reduce waste, and link you ever more closely to customer value. This practice will help you develop better self-awareness, more disciplined problem-solving skills, and the ability to self-correct errors.
 
This book not only provides the tools, but also teaches you how to find the root causes underlying your inefficiencies so you can eliminate them permanently. It will enable you to immediately improve personal productivity while developing the skills needed for continuous improvement. It includes real-world examples that illustrate how these principles have been successfully applied across a range of industries. Providing the perfect mix of what-to-do with why-to-do it, the text details a step-by-step approach to applying Lean principles to your work.
 
As if you did not have enough books and articles to read!  But the payoff for reading these two books may will be worth the effort to spend since if you're already doing Agile, you are already familiar with the tools to become instantly productive for personal projects.  For thoese new to Agile, what better way to start realizing the benefits than to see them in your personal life!
 
In this light, Agile is definitely starting to get pretty personal but in a very good way.
A Factory of One: Applying Lean Principles to Banish Waste and Improve Your Personal Performance describes how you can foster a new mindset and improve your performance by applying Lean methods to your work. It translates powerful Lean tools such as visual management, flow, pull, 5S, and kaizen to your daily work, revealing how they can help to improve efficiency, reduce waste, and link you ever more closely to customer value. This practice will help you develop better self-awareness, more disciplined problem-solving skills, and the ability to self-correct errors.
 
This book not only provides the tools, but also teaches you how to find the root causes underlying your inefficiencies so you can eliminate them permanently. It will enable you to immediately improve personal productivity while developing the skills needed for continuous improvement. It includes real-world examples that illustrate how these principles have been successfully applied across a range of industries. Providing the perfect mix of what-to-do with why-to-do it, the text details a step-by-step approach to applying Lean principles to your work.
Posted on: September 17, 2013 01:34 PM | Permalink | Comments (1)

Become a Professional Scrum Master without taking a course

linkedin twitter facebook Request to reuse this  

Seems the Scrum certification battles are heating up!  The Scrum.org group founded by Ken Schwaber, the original co-founder of Scrum who broke with Scrum Alliance a couple years ago due to his dissatisfaction of where that group was heading, has now made obtaining their Scrum Master certifications such as the Professional Scrum Master (PSM) simply a matter of taking and passing their online assessments:

The Professional Scrum Master level 1 (PSM I) assessment is available to anyone who wishes to validate his or her fundamental knowledge of the Scrum framework and its application. Those that pass the assessment will receive the industry recognized PSM I Certification to demonstrate their mastery of the content.
 
Taking a course is not required. While a 2-day Professional Scrum Foundations or Professional Scrum Master course is highly recommended, if you feel you already possess a high level of Scrum knowledge, you have the option to take the PSM I assessment directly. The PSM I assessment is grounded in the Scrum Body of Knowledge at Scrum.org, but is quite difficult. Parts of the assessment may ask the taker to think about or interpret the meaning from the Scrum Guide. Or, in some cases, apply their own experience. 
 
I wouldn't be surprised to see the Scrum Alliance take a similar route and I would imagine that this will have implications for those who make their living as Scrum trainers and coaches.
The Professional Scrum Master level 1 (PSM I) assessment is available to anyone who wishes to validate his or her fundamental knowledge of the Scrum framework and its application. Those that pass the assessment will receive the industry recognized PSM I Certification to demonstrate their mastery of the content.
 
Taking a course is not required. While a 2-day Professional Scrum Foundations or Professional Scrum Master course is highly recommended, if you feel you already possess a high level of Scrum knowledge, you have the option to take the PSM I assessment directly. The PSM I assessment is grounded in the Scrum Body of Knowledge at Scrum.org, but is quite difficult. Parts of the assessment may ask the taker to think about or interpret the meaning from the Scrum Guide. Or, in some cases, apply their own experience. 
Posted on: September 09, 2013 08:40 AM | Permalink | Comments (1)

Does Kanban really matter for Agile?

linkedin twitter facebook Request to reuse this  

I think it does and this webinar outlines why Kanban matters for Agile teams:

It's a nice general introduction and for those with a PMP and/or PMI-ACP certification, you can receive 1 PDU for watching since the webinar is just over an hour long.

Enjoy!

Posted on: September 03, 2013 04:15 PM | Permalink | Comments (3)

The Yin-Yang of Agile-Lean

linkedin twitter facebook Request to reuse this  
I thought it was interesting thatI thought it was interesting that an article in the very mainstream Huffington Post is about the application of Agile to one’s personal life.  It goes on about how to use “retrospectives” as a way to step back, stop and review where one is in life and plan forward just enough to get the highest priority items done.  This is sound advice which I think we all agree.
I thought it was interesting that an article in the very mainstream Huffington Post is about the application of Agile to one’s personal life.  It goes on about how to use “retrospectives” as a way to step back, stop and review where one is in life and plan forward just enough to get the highest priority items done.  This is sound advice which I think we all agree.
 
But one quote in particular caught my eye which is when the author Michele Serro states:
 
“Lean is a predominantly entrepreneur discipline; its aim is to build the right thing. Agile is predominantly a developer discipline; its aim is to build the thing right.”
 
In general, I think that’s a pretty good way of comparing the two methods as it puts it in the perspective of a kind of Yin-Yang relationship and accounts for why Lean has become a quite popular and growing addition to the Agile suite of methods.  Think of terms like value stream, Kaisen, Kanban, etc. in the Agile vocabulary and this is truly the case.
 
In the final analysis, what this nice little quote is indicative of is that fact that we need to see and think more about how the various Agile processes and methods complement and integrate with each other, which is a bit more Eastern approach, rather than to view these as separate and distinct concepts applicable to a specific domain, which is a more Western perspective.
 
What do you think?  Do you mainly view the complementary aspects of Agile or the distinctness of them?  Which is better?
What do you think?  Do you mainly view the complementary aspects of Agile or the distinctness of them?  Which is better? an article in the very mainstream Huffington Post is about the application of Agile to one’s personal life.  It goes on about how to use “retrospectives” as a way to step back, stop and review where one is in life and plan forward just enough to get the highest priority items done.  This is sound advice which I think we all agree.
 
But one quote in particular caught my eye which is when the author Michele Serro states:
 
“Lean is a predominantly entrepreneur discipline; its aim is to build the right thing. Agile is predominantly a developer discipline; its aim is to build the thing right.”
 
In general, I think that’s a pretty good way of comparing the two methods as it puts it in the perspective of a kind of Yin-Yang relationship and accounts for why Lean has become a quite popular and growing addition to the Agile suite of methods.  Think of terms like value stream, Kaisen, Kanban, etc. in the Agile vocabulary and this is truly the case.
 
In the final analysis, what this nice little quote is indicative of is that fact that we need to see and think more about how the various Agile processes and methods complement and integrate with each other, which is a bit more Eastern approach, rather than to view these as separate and distinct concepts applicable to a specific domain, which is a more Western perspective.
 
What do you think?  Do you mainly view the complementary aspects of Agile or the distinctness of them?  Which is better?
Posted on: August 27, 2013 11:32 AM | Permalink | Comments (2)

Is Agile too flexible for its own good?

linkedin twitter facebook Request to reuse this  
Yes, we all know andYes, we all know and love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far?  It could be that the promotion of the flexibility cause both teams, stakeholders and customers to expect and demand too much flexibility which causes too many and difficult to manage changes  leading to project delays, quality problems and teams that had difficulty delivering value.  
Yes, we all know and love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far?  It could be that the promotion of the flexibility of the method is what causes both teams, stakeholders and customers to expect and demand too much flexibility.  This causes too many and difficult to manage changes leading to project delays, quality problems and teams that had difficulty delivering value.  
 
Is Agile too flexible for its own good?
 
In this article by Lajos Moczar in CIO magazine, he thinks the whole method is flawed:
 
Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.
 
I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here…
 
In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes. Every change has a cost, but agile does not account for this. The result?  People often change really big things late in the game using the rationale that since it's an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.
 
From my perspective, it isn’t so much that Agile is too flexible, but rather that people are too flexible in their use of Agile.  I think the real flaw is to blame the method for being flawed due to misuse, rather than one’s misuse as being the flaw that causes flawed results.  For example, it’s like blaming a hammer for being a flawed tool because you tried to use it to hammer a screw into a wall, rather than admitting that your flawed use of the hammer is what cause screw to damage the wall.
 
I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself.  What do you think?
I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself.  What do you think? love the Agile principle of “responding to change over following a plan”, but have some Agile adopters taken this notion too far?  It could be that the promotion of the flexibility cause both teams, stakeholders and customers to expect and demand too much flexibility which causes too many and difficult to manage changes  leading to project delays, quality problems and teams that had difficulty delivering value.  
 
Is Agile too flexible for its own good?
 
In this article by Lajos Moczar in CIO magazine, he thinks the whole method is flawed:
 
Much of agile's success is due to the fact that it "sells" so well by promising solutions to perennial IT concerns: projects that run over budget and time, lack of team effectiveness, lack of true collaboration, poor product quality and dissatisfied customers.
 
I've been involved in a number of agile projects from all perspectives, as a team member, leader architect and overall responsible manager. I've concluded that agile has not only failed like other fad methodologies before it but, in fact, is making things worse in IT. Yes, there are certain occasions when agile does work, particularly for proof of concept (POC) work involving already well-integrated teams, but I'm talking about 80 percent of projects here…
 
In theory, developers code while collaborating with stakeholders to define, refine and change requirements as the projects goes along. The methodology, however, does not distinguish between big and small changes. Every change has a cost, but agile does not account for this. The result?  People often change really big things late in the game using the rationale that since it's an agile project, it can handle it. The only way the project can handle this is by adding iterations. As that happens, defects that might have been easy to fix at one point get harder and harder to fix, since the code base keeps changing.
 
From my perspective, it isn’t so much that Agile is too flexible, but rather that people are too flexible in their use of Agile.  I think the real flaw is to blame the method for being flawed due to misuse, rather than one’s misuse as being the flaw that causes flawed results.  For example, it’s like blaming a hammer for being a flawed tool because you tried to use it to hammer a screw into a wall, rather than admitting that your flawed use of the hammer is what cause screw to damage the wall.
 
I think this is a common fallacy since it’s easy to blame the tool rather than to blame yourself.  What do you think?
Posted on: August 12, 2013 11:37 PM | Permalink | Comments (4)
ADVERTISEMENTS

"Humanity has advanced, when it has advanced, not because it has been sober, responsible and cautious, but because it has been playful, rebellious and immature."

- Tom Robbins

ADVERTISEMENT

Sponsors