Do you really need a long definition of done? We in Adform think not!

We are always trying to improve process and they way of working, but don’t forget to hire great people.

Here is the reminder from Steve Jobs (RIP) about importance of great employees! (from fastcompany.com)

Understanding these simple things help me in my daily work.

1. It’s impossible to gather ALL the requirements
2. Whatever requirements you have are guaranteed to change
3. There is always more to do than you have time and money allow

So, it’s only left to convence customers and developers that you can do nothing about it. And we must work together flexibly to make our lives a bit easier

When someone tries to start using Scrum inevitably there are a lot of discussions about definition of done. You will hear a lot of things starting from design documents and ending with unit tests. But it becomes very obvious what must be included into definition of done when you imagine something not related with software.

Imagine a situation that you decided to paint you room with a new color. Since you are not able to do this by yourself (it might not be a case in your situationJ) you are going to hire external specialists. So, these specialists return to you in two weeks with following output:

• Elegant design of the room
• Report how they planned to paint the room
• Analysis of different colors
• Half painted room with low quality
• Tools scattered around

Are you going to be happy as a customer? Is this what you want? So, when you are going to have a discussion about definition of done, please take real value into account first and don’t forget the quality.

p.s. despite the common sense discussions about definition of done are always quite difficult and it is not so easy to come to a common agreement.

Each scrum master presents a hot topic for his team during the retrospective of retrospectives.
It leads to very interesting discussions and better understanding of the topic.

How do you do it in yours scrum adoption?

While browsing Agile forums on LinkedIn i found interesting and easy question “What is Agile?”. My first thought was – it’s easy … and i realized that even though i have a lot of thoughts on that, but i realized that it is not fully clear for me. So, main goal of this post is to clarify it for myself

First of all Agile is an alternative way of software development which is based on principles behind Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The suggested principles are very simple and flexible, but very difficult to apply. I personally like this one most of all:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

This last principle fully explains to me “What is Agile?” – it means you are always seeking for improvement and you will change if environment changes around you. So, it is not a methodology (as i read somewhere), but it is the way of thinking and working, a mindset.

Everything started from the desire of improving software development process, but such way of thinking can be applied to whole organization. Because these principles only describe how to tackle problems in the best way.

Agile is not a methodology, process or something else. It’s a mindset!

This picture doesn’t need any comments, found it here – http://blog.smartbear.com

SmartBear Software Agile Solutions

That’s why you release not feature complete or quality ready software! http://t.co/qn0CbiaC #pm #in — ruckiand (@ruckiand)

The most important thing in problem solving is two choose which problem to solve. There are two main criteria:
- Problem that have biggest impact on business
- Problems that can be solved quickly and engage others

Everything else is not important…

I’ve read interesting article about sustainable pace recently. The more we use Scrum as a framework for our development approach the more i feel importance of sustainable pace, especially on organizational level.

Here is one article on this topic on Scum Alliance website - http://www.scrumalliance.org/articles/350. Is sustainable pace just a nice to have? Definitely not!

Some ideas how to keep sustainable pace on a team level:

1. No time sheets, no fixed working hours, not even a suggestion that you are “required” to work 8 hours a day. Set expectations about what people are supposed to deliver.
2. Focus rather on getting things done than being busy. If you are having a pointless day go home. If you are on fire and getting things done – keep going. To paraphrase Kent Beck “every hour at the office that you don’t want to be there is overtime”
3. No work on weekends
4. Do Fedex days, learning sessions. Any other activities that are not related to daily tasks.