XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Archive for the ‘Crib’ Category

Done with Definition of Done or Definition of Done Considered Harmful

Monday, January 26th, 2015

TL;DR: Definition of Done (DoD) is a checklist-driven project management practice which drives compliance and contract negotiation rather than collaboration and ownership. Its very easy for teams to go down rat-holes and start to gold-plate crap in the name of DoD. It encourages a downstream, service’s thinking mindset rather than a product engineering mindset (very output centric, rather than outcome/impact focused.) Also smells of lack of maturity and trust on the team. Bottom line: Its a wrong tool in the wrong people’s hand.

The Scrum Guide™ describes DoD as a tool for bringing transparency to the work a Scrum Team is performing. It is related more to the quality of a product, rather than its functionality. The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

They recommend that having a clear DoD helps Scrum Teams to:

  • Work together more collaboratively, increases transparency, and ultimately results in the development of consistently higher quality software.
    • Clarifies the responsibilities of story authors and implementors.
  • Enables the Development Team to know how much work to select for a given Sprint.
    • Encourages people to be clear about the scope of work.
  • Enable transparency within the Scrum Team and helps to baseline progress on work items
    • Helps visualize done on posters and/or electronic tools.
    • Aids in tracking how many stories are done or unfinished.
  • Expose work items that need attention
  • Determine when an Increment is ready for release

Also according to them, DoD is not changed during a Sprint, but should change periodically between Sprints to reflect improvements the Development Team has made in its processes and capabilities to deliver software.

According to the LeSS  website– DoD is an agreed list of criteria that the software will meet for each Product Backlog Item. Achieving this level of completeness requires the Team to perform a list of tasks. When all tasks are completed, the item is done. Don’t confuse DoD with acceptance criteria, which are specific conditions an individual item has to fulfil to be accepted. DoD applies uniformly to all Product Backlog items.

Examples

If you search online, you’ll find sample DoD for user stories more or less like this:

  1. Short Spec created
  2. Implemented/Unit Tests created
  3. Acceptance Tests created
  4. Code completed
  5. Unit tests run
  6. Code peer-reviewed or paired
  7. Code checked in
  8. Documentation updated
  9. 100% Acceptance tests passed
  10. Product Owner demo passed
  11. Known bugs fixed

Another example:

  1. Upgrade verified while keeping all user data intact.
  2. Potentially releasable build available for download
  3. Summary of changes updated to include newly implemented features
  4. Inactive/unimplemented features hidden or greyed out (not executable)
  5. Unit tests written and green
  6. Source code committed on server
  7. Jenkins built version and all tests green
  8. Code review completed (or pair-programmed)
  9. How to Demo verified before presentation to Product Owner
  10. Ok from Product Owner

Do you see the problem with DoD? If not, read on:

Problems:

  • Checklist Driven: It feels like a hangover from checklist driven project management practices. It treats team members as dumb, checklist bots. Rather than treating them as smart individuals, who can work collaboratively to achieve a common goal.
  • Compliance OVER Ownership: It drives compliance rather than ownership and entrepreneurship (making smart, informed, contextual decisions.)
  • Wrong Focus: If you keep it simple, it sounds too basic or even lame to be written down. If you really focus on it, it feels very heavy handed and soaked in progress-talk. It seems like the problem DoD is trying to solve is lack of maturity and/or trust within a team. And if that’s your problem, then DoD is the wrong focus. For example, certain teams are not able to take end-to-end ownership of a feature. So instead of putting check-points (in the name of DoD) at each team’s level and being happy about some work being accomplished by each team, we should break down the barriers and enable the team to take end-to-end responsibility.
  • Contract Negotiation OVER Collaboration: We believe in collaboration over contract negotiation. However DoD feels more like a contract. Teams waste a lot of time arguing on what is a good DoD. You’ll often find teams gold plating crap and then debating with the PO about why the story should be accepted. (Thanks to Alistar Cockburn for highlighting this point.)
  • Output Centric: DoD is very output centric thought process, instead of focusing on the end-to-end value delivery (outcome/impact of what the team is working on.) It creates an illusion of “good progress”, while you could be driving off a cliff. It mismanages risks by delaying real validation from end users. We seem to focus more on Software creators (product owners, developers, etc.) rather than software users. Emphasis is more on improving the process (e.g. increasing story throughput) rather than improving the product. Ex: It helps with tracking done work rather than discovering and validating user’s needs. DoD is more concerned about “doing” rather than “learning”. (Thanks to Joshua Kerievsky for highlighting this point.)
  • Lacks Product Engineering Mindset: Encourages more of a downstream Service’s thinking  rather than a product engineering mindset. Unlike in the services business, in product engineering you are never done and the cycle does not stop at promoting code to high environment (staging environment). Studying whether the feature you just deployed has a real impact on the user community is more important than checking off a task from your sprint backlog.

What should we do instead?

Just get rid of DoD. Get the teams to collaborate with the Product Management team (and user community, if possible) to really understand the real needs and what is the least the team needs to do to solve the problem. I’ve coached several teams this way and we’ve really seen the team come up with creative ways to meet user’s need and take the ownership of end-to-end value delivery instead of gold-plating crap.

Twitter pushing Ads in between my Stream #Fail

Wednesday, November 21st, 2012

On my iPhone Twitter app, I’ve noticed that Twitter has started pushing ads in between my stream. The look and feel of the ad is very similar to the normal tweets. One needs to carefully look at the bottom of the tweet and it would say: Promoted by xxx – WTF?

Facebook and Twitter Icons on Print Media

Friday, May 18th, 2012

These days its fashionable for businesses to have a Facebook and Twitter account. I can see how social media can help them. But what beats me is, every now and then, I see a billboard or a poster with just Facebook and Twitter icons in one corner of their printed ad. What does this mean?

Its like having visiting card like this:

Instead of:

 

After 6 Years We’re Still Struggling to Establish Any Sustainable Community/Special Interest Group in India

Saturday, May 28th, 2011

For the last 6+ years, few of us in India, are trying to establish a sustainable Agile community. The truth is that we are still struggling to have a self-sufficient, self-driven community.

We don’t seem to be hosting regular user group meetings. Our sporadic events seem to attract mostly new people each time. Next meeting we rarely see them. Huge number of people sign up, but only a fraction show up.

Its not just the Agile community, we’ve tried many other communities like .Net User Group, TechCamp, GeekNight, BarCamps, etc. Except the Linux community (FOSS now) I don’t think any other software community has really sustained itself.

This is very contrary to what I saw when I used to facilitate the Agile Philly User Group and the Philly GeekNight. People used to drive 2 hrs to attend the meeting. We had the same set of people coming every meeting. We all had this sense of learning and growing together.

What do you think is different in India?

IMHO the biggest problem I see is that there is so much “mediocre job opportunity” available, that frankly software professionals can be in demand for many years without learn anything new. With many people I sense a “there-is-no-need-to-stretch-ourself” attitude. Necessity is the mother of innovation and action. People don’t see the necessity. Period.

There are very few people I know who care about learning and exploring and growing.

Some other problems I see:

  • For most people, there is no end to mediocre opportunities and they are happy with it. “This job sucks, but its OK, I get a decent salary.” kind of attitude. The ones who want to purse big dreams mostly move to US or other places. (There are always exceptions to the rule.)
  • With all the personal, social life & society obligations and working late to catch up with counterparts in other countries, there is very little time left for user groups and other initiatives. Even if one is interested, the traffic and other logistics make it next to impossible to motivate people.
  • There is country culture, but the biggest culprit is the Organization culture. At certain places I’ve worked, if you are not learning new stuff, you feel like a piece of shit. But in many other companies I’ve visited, that’s not the case.
  • Indian Software Industry is unfortunately very “brand conscious“. If its a big name speaking at an event, people will walk a whole day to attend the event. But if its a local speaker presenting, it doesn’t appeal.

I’m sorry if you find me ranting, but I’m disappointed with the attitude. I’ve almost lost hope, but may be you can show me the light.

Stop Sprinting, Start Minting

Friday, October 23rd, 2009

These days, its common to see teams doing the Product Backlog Management to Sprint Planning t0 Daily Scrums to Reviews to Retrospectives perfectly fine, as described in the book (or the 2 days Certified Scrum Master course). We are doing all the process stuff correctly, except that we don’t seem to be”actually” making money (minting). But somehow along the way, we seemed to have missed the point.

The problem I see is, teams are doing all the process stuff, as they are told, except that, post demo they don’t actually release the software (deploy it into production). Most teams are very happy showing the demos at the end of the sprints. They start thinking that this new process they are following is magical. Until 6 months later, their so-called “Product Owner” comes backs saying I didn’t quite expect “this” this-way and I thought “that” would be “this” and not really “that”. That is when it hits the team that what they were really doing was building inventory and basically doing a compressed-waterfall.

Until you actually release your software and see your end-users actually use it in real life, you don’t have the most important feedback. Hence you are not “done” until you really see you users use the feature you just released (and probably you are not even done after that. “Done-Done” was a cute concept, get over it). There is no better means of feedback nor is there a better risk-reduction strategy other than releasing software to production frequently (at least every week).

Remember code that is not yet deploy and just sitting in your repository is a liability. So is, all your fancy product backlogs and grandiose plans.

Annoyed by the amount of Energy wasted in US

Thursday, August 27th, 2009

I’m in Chicago attending the Agile 2009 conference. I’m getting really annoyed by how much energy is being wasted here:

  • Everything (soda, water, lemonade) has a ton of ice in it. Just think of the amount of energy wasted having those coolers running 24/7.
  • Central Air-conditioning: Every conference room, hall way, lobby is set at 60F (15.5c). You see people wearing full sleeves, pullovers, etc.
  • Stair cases have been replaces with escalators everywhere.
  • I have hot water in the taps 24 hrs a day
  • People using treadmills instead of going out and jogging.
  • The list can go on…

While the world is crying about Global Warming, Energy Crisis, and so on. Here I find energy being wasted wasting senselessly. I’m not sure if people don’t care or they are ignorant or they simply not aware of the implications.

P.S: I’m also annoyed by the amount of waste (plastic and paper) generated. The funny thing is, everywhere you have these different color dust-bins with recycle logo on it. But you’ll find people use 5 different plastic glasses if they want to drink 5 glasses of water. I don’t think they get the whole point.

Interested in Agile Training/Consulting for your Organization?

Monday, June 29th, 2009

Recently I’ve been getting a lot of request for Agile Training and Consulting. Unfortunately the expectations from the training are not clear for me. Most people approach me saying, “we want a TDD training” or “we want a Project Management training“. Once I start talking to them & their team (or even worse sometime during the training), I realize the topic we’re discussing is not their biggest issue. I get a feeling that most organizations have not done their homework to figure out what they really need and how they should go about it. They might have heard somewhere that ‘blah’ will help them and they want to jump on it.

Few months ago I started doing readiness assessments before my trainings. (I’ve also started doing assessments after my training so see if the training was effective.) But I have realized the assessment is not enough. So I’ve started asking the following questions even before the assessments:

  • What kind of issues your organization is facing currently and do you think Agile will help you? If yes, why so?
  • What is the current strength of your development team? How experienced is the team with software development? Does your team understand all aspects of software development?
  • What is the current process you follow? In other words, from the inception of an idea to the delivery of the same, what are the various steps and people involved?
  • What is a day in life of a team member (one per role please)?
  • How do your stakeholders (including customers) perceive your team/organization? Currently how do you gather feedback from them?
  • How would you rate the technical know-how of your team? Are they able to quickly resolve technical challenges and respond to changing priority of the business?
  • Is your team/organization open to trying out things that might seem non-intuitive/illogical? For Ex: Letting the requirements evolve during the project, not freezing them? Letting tests drive your design?
  • And so on …

Luckily a lot of organizations don’t get back to me with answers for these questions. This is really good for me, because this acts as a filtering criteria. I feel I would have wasted my time training/coaching this team. There are others who are in much more need and are more receptive to what I’ve to contribute.

Most Common Agile Adoption Pattern

Tuesday, May 5th, 2009

Someone, really high up the hierarchy (one of the CxOs), after reading a bunch of case studies and reports, decides Agile is the way to go. She builds a business case and announces

We’re going Agile. This will solve all our problems. Our software products will be delivered faster than light.

Hand picked set of managers are sent to the near-by, favorite Scrum Certification course. And from that day onwards, the army of software slaves wear their Agile uniforms and start marching. Starting with those pre-pre-pre-pre-poker; sorry planning meetings to the re-re-re-review meetings to the daily (ouch my legs hurt) scrums. And of course the wet-row-spectives.

After doing all this, your company don’t even see the light, forget delivering products at lightening speed. Then of course you hire a X-Stream black-belt consultant to explain you why you need another Engineering process to succeed. So you start doing TDD, no BDD, no TDD, no RDD with automagic retractoring and revolutionary markitecture. Knowledge of resign patterns is mandated. You also instill the promiscuous rare-programming with sustainable mace and so on.

You continue down this path cursing yourself that you are not good enough. Only if you had the right set of people perfectly following the process, you could see fluffy bunnies jumping all over the place.

Software Development continues to be Episodic

Saturday, May 2nd, 2009

I guess you agree with me that software development is a continuous evolutionary process. While developing a software product one should be in a flow mode rather than an episodic mode. As Sandeep puts it, its activity v/s events. This goes back to the philosophy of eXtreme programming.

If something is good, do it all the time OR as they say, push the nob to 10.

  • We realized that integrating early and often is good, hence we started doing Continuous Integration.
  • We realized that we cannot plan once and then just follow the plan, we need to continuous keep planning and prioritizing work.
  • We realized that code reviews are helpful, hence we started Pair Programming.
  • We realized that testing early and often is good, hence we started Test Driven Development.
  • We realized that one cannot think of all scenarios and design software upfront. Since software keeps evolving and software degrades (bit-rot) over time, we need to refactor code all the time (mercilessly).
  • And so on.

This is what I mean by flow mode (activity) rather than an episodic mode (event).

In Agile, we’ve tried to apply this principle in various places like

  • Product Visioning
  • Managing Product Backlogs (Requirements)
  • Release Planning
  • Iteration Planning
  • Retrospective
  • User feedback
  • Daily Stand-up meetings
  • And so on…

But what I feel is a lot of it is still very episodic. For example,

  • If a developer hits a road block, they sit on it till the next day’s stand-up meeting. Because stand-up meeting is where we discuss roadblocks.
  • If we find something is hurting us, we wait till the retrospective to discuss about it.
  • If we discover some acceptance criteria cannot be met or is flawed during the iteration, we wait till the demo to communicate that with the customer/product owner.
  • If we discover a new killer feature during an iteration, we wait for the planning meeting to discuss that and prioritize it on the backlog.
  • We wait till the end of the release to do Performance testing, Hallway Usability testing and other important tests.
  • And so on….

The Lean community is trying to address a lot of these issues. As long as we think of software development activities as episodes and not as continuous flow of activities it would be very difficult to really implement kaizen and evolve.

Yahoo Groups: Moderated Messages

Friday, March 6th, 2009

Yahoo Groups’ message moderation is behaving weirdly (I think its a bug). I moderate various groups on YG. For all the groups, I’ve setup posting to the group such that first post from any new member will be moderated and after that they can post messages without moderation.

But for a large number of members, for some reason, all their messages are moderated. On checking their setting it shows:

“Posting Messages: Override: This member’s posts are always moderated”

I don’t understand why YG is behaving this way.

Solution: Edit the user’s membership. Under the edit membership page, there is a small edit link next to the “Override: This member’s posts are always moderated”.

Once you click on the edit link, it takes you to Edit Message Posting Privileges page where you’ll have to select the “Use current group message posting setting” option.

Save the settings and you should be good to go.

    Licensed under
Creative Commons License