Chaos Report, Agile and your company

Posted on Leave a commentPosted in management

I’ve never read Chaos Report before, but heard a lot about it. So decided to find out what it is all about. Not sure if this is THE one, but i managed to find document with word chaos in the title dated 2010. ūüôā This was extremely interesting reading.

This document lists all typical problems projects have and explains what exactly doesn’t work. And do you really expect that “Agile” is out of the box solution for these problems?

  • User¬†involvement

Scrum and Kanban are supposed to solve this problem. But what you can notice in most cases that PO becomes a proxy for a team and users are still far away from developers and feedback is not provided.

You still need to ensure business communication (talk their language), align understanding of quality (usually it’s different for developers and users), manage expectations

  • Clear business objective

The fact that your users are not close enough to your team and you don’t know what and why you are doing, most probably will lead you nowhere in a long run.

  • Law of long-tailed monster¬†

You will always build too much of what you don’t need and not enough of what you need. So you know what will happen if ¬†you have the fastest development process in the world, but don’t spend enough time on thinking what you are doing – pile of not useful crap.

  • Panda’s Law

Inaction is failure. So if you don’t know which alternative to choose don’t spend hours/days months in discussions. Take actions and learn fast.

  • Law of Fools

I think you saw million of times when people are looking for a tool, not a problem’s solution, but “Fool with a tool is still a fool”. That’s why we often hear that Scrum, Kanban or whatever fails. Do you really know what problem you are solving? Do you have enough knowledge about these tools and how they should be used?

Power is not in the methodology or a process, but in an open mindset and ability to change and adapt!

You can download the document here – http://insyght.com.au/special/2010CHAOSSummary.pdf

Scrum, Kanban is your goal? – NO

Posted on 1 CommentPosted in management, process

Before implementing any Agile framework like Scrum, Kanban – make sure you understand your goal. Recently was reading one thread in AgileRussia forum with following comment: “I am aiming to achieve SCRUM”. Hm..

Are you sure that process itself is your goal? Sometimes it feels that people are more concerned about the process rather than values they really want to achieve.

Our goal is:

  • happy client;
  • product with a high quality;
  • great work environment;
  • short “time to market”.

It doesn’t matter what process you apply. Use the process only as a TOOL!

Notes from Agile event

Posted on Leave a commentPosted in management, personal improvement

Agile events are interesting because of the only reason – meeting people and hearing their opinions. Everything else you can find in books.
I’ve been to AgileRigaDay at the start of March and made some notes listening to key speakers –¬†http://www.agilerigaday.lv/speakers

Importance of Feedback (Ola Elnestam)

It’s important not to give feedback, but act based on it!

If you have to prove your customer that certain (read agile/lean/…) development approach is better than another, than it is something wrong in your relations!

What is Agility? (Vasco Duarte)

I am Agile – what does it mean to you?

  • Don’t fight who is more Agile! It’s just doesn’t make sense. Think about value!
    • Do you feel Agile in you projects?
  • If you perform certain practices like stand-up, sprints and etc… does it mean that you are Agile now?

Note: Main difference between Agile and Waterfall projects is sense of responsibility:

  • In Agile environment people take responsibility for what they do
  • In waterfall – no one knows anything

Agile and Lean (Joakim Sundén)

Scrum vs Kanban – NO… Scrum and Kanban!
Kanban focuses on flow mainly, make your flow as short as possible.
Understand how the work works!

Key values of Kanban – stimulate a conversation with WIP (work in progress) and visualization of work.
Some things to remember about Kanban:

  • No celebration in Kanban
    • Hm, just do it. No one says you can’t.
  • You can have time box for each WIP
  • Don’t use Kanban as an excuse for failed SCRUM
  • Stop starting things, start finishing‚Ķ

Agile adoption (Zuzana Sochova)

Most difficult things in agile adoption:

  • Story Points
  • Test driven development
  • Pair programming

Things to remember about Agile:

  • Communication is everything
  • Involve everyone and make sure everyone understands Agile
  • Make collaborative culture

Before implementing Agile decide the following:

  • Where you are
  • Where do you want to go
  • If you are ready for change

Adoption will work if you:

  • Believe in culture/people
  • Embrace change and overcome resistance
  • Have willingness to take risks
  • Have desire for agile methods

Don’t sell Agile as DOGMA!

p.s. don’t sell anything as dogma

Scrum is only an iterative approach – Part II

Posted on Posted in management
The provocative statement from my previous post was posted into the Scrum Alliance forum. And i got very interesting answers.
I decided that these answers are very correct and worth sharing. And I must admit these answers helped me to clarify some issues which probably are not so obvious at the first glance. Please see some of the answers below.
p.s. my question from post is in italic.
Yves Hanoulle
> Hi All,¬†Don’t you think that Scrum is pretty much the same as RUP, XP and¬†other iterative software development approaches?¬†XP and scrum are more alike then RUP

Important part of scrum and xp is the self-organizing part.¬†Calling them only “iterative development” might look technically correct, it¬†is wrong.

> And the only difference among them is the number predefined rules to follow. For example RUP has the most, Kanban has the least.
> I don’t think the Kanban people would agree that Kanban is iterative.¬†But no matter which iterative approach you are planning to use you
> need to adapt it to your organization. In case of Scrum or Kanban each team comes up to its own rules, but in case of RUP you can adjust/change already predefined rules.

which is why they are totally different.

> So I think the main power is in ITERATION and its CLEAR GOALS, but everything else depends on what you prefer.

that is how these approaches differ for you. Not for me.

Gustavo Cebrian Garcia

Yes, there is a few similarities, of course but, I would tell you that you have to understand that the Scrum philosophy is much more: Visual Management, Retrospectives and what about all the books writen which advice you on very good practices?

When you say iterative process, you make it look very simple. But tell me,¬†what practices do you do to succeed, and tell me if you can learn more ūüôā¬†(not trying to be¬†aggressive¬†at all !!)
A name and a concept are very abstract, and they do not define details¬†(good practices) Scrum, is about people, experiences, good practices and¬†sharing all that knowledge…¬†The Scrum knowledge tells you much more that RUP, in my opinion.¬†Hope you know what I mean.
Bachan Anand

Good question , got me thinking this morning.

> Don’t you think that Scrum is pretty much the same as RUP, XP and¬†other iterative software development approaches?

I do agree that Iterative approach to problem solving is part of Scrum framework and we can draw some parallels between RUP and Scrum in this regard.

> And the only difference among them is the number predefined rules to follow. For example RUP has the most, Kanban has the least.

I also see as RUP as a very defined process where as Scrum is a framework with lesser defined rules on how to approach the problem and focus is on values and principles. Most of the Scrum rules are backed up by the foundations like focus, empiricism, collaboration , self organization. So I believe the purpose behind Scrum rules are explicit and backed up by foundation and values and not just as best practices that worked in some other context . I have been able to effectively able to use those underlying foundations and values when adapting Scrum to different environment and use it as a general management and problem solving approach in different contexts.

> But no matter which iterative approach you are planning to use you
> need to adapt it to your organization. In case of Scrum or Kanban each team comes up to its own rules, but in case of RUP you can adjust/
> change already predefined rules. So I think the main power is in ITERATION and its CLEAR GOALS, but everything else depends on what you prefer.

I totally agree that adapting any process to your organization is key for the success of any way of working. What Scrum provides is a set of rules(simple for some , not so simple for other based on your outlook towards some of the Scrum values and how much you can stand behind them) . For me the beauty of Scrum lies in the autonomy (self organization ) , ownership (commitment) and importance Scrum places on people interaction between people. I have not seen that being explicitly stated by other frameworks, I am hoping that more and more frameworks value people over processes. Explicit reference to transparency and courage in believe is a great way of surfacing impediments and dysfunctions and effectively resolving them. Finally it all depends on the people involved and how much they can internalize the values and foundation to achieve success with Scrum rules.

Great question again.
Ron Jeffries and Kurt Hausler

Kurt: I get the feeling that most people are using it as a mere planning and scheduling tool, rather than a tool to surface problems, and promote organizational change. I suspect a lot of people are just using it embedded in the development departments/phase within a waterfall process rather than as a replacement for waterfall at a higher level. Both of which are hard to argue against if the scrum guide is being used to defend them. I would rather see the scrum guide take a bolder approach, and condemn such a watered down approach to scrum.

Ron: +1, with “many” substituted for “most”.
My conclusion: There is no silver bullet!

Scrum is only an iterative approach

Posted on 1 CommentPosted in management

Don’t you think that Scrum is pretty much the same as RUP, XP and other iterative software development approaches?

And the only difference among them is the number predefined rules to follow. For example RUP has the most, Kanban has the least.

But no matter which iterative approach you are planning to use you need to adapt it to your organization. In case of Scrum or Kanban each team comes up to its own rules, but in case of RUP you can adjust/change already predefined rules. So I think the main power is in ITERATION and its CLEAR GOALS, but everything else depends on what you prefer.

I posted this thought¬†here, let’s see what answers will i get.