Meeting Acceptance Criteria Implies Customer Satisfaction

checklist

It doesn't matter if your model is Kanban, Agile, Waterfall, or RUP.  You can't close out a project or task without first identifying the Acceptance Criteria.  Acceptance criteria begins to take shape during the first moments of a project or task. If you are utilizing Kanban or Agile, everything pertaining to your deliverable should be captured on your story cards.  This includes story details and acceptance (testing) criteria.  Satisfying all acceptance criteria implies the needs of the customer have been met.

If you following Waterfall, RUP, or similar model, you would expect to identify acceptance criteria, along with scope description and project deliverables, in the project scope statement.  (These are each components of a scope baseline)

It all goes back to requirements and stakeholders' satisfaction.  Remember each requirement should add business value by linking to a business or project objective(s).

Those criteria, including performance requirements and essential conditions, must be met before project deliverables are accepted. Regardless of your model, spare yourself a lot of wasted time AND money by documenting acceptance criteria early.

How To Effectively Manage An Offshore Team Of Developers

There are probably two primary reasons you would go with an offshore team. (1) Your customers are also offshore, or (2) you're hoping to save money on development costs.

I'm going to assume your reason is number (2).  Though this post is brief for such a complicated topic, it should give you some things to think about.  Yes, you can certainly save a lot on development expenses. Then again, it can come back to bite you in rework expenses if there are communication issues.

How do you bridge the language barrier? (1) You need a go-to guy or gal who speaks the same language as your developers but will be working at your location. This is a must. Your probability for success is going to go way up by ensuring there is no breakdown in communications.

How do you receive the quality of code you need? (1) Use continuous integration (2) Use test scripts to understand requirements (3) Use short iterations (4) Have regular builds (5) Separate teams by functionality (not activity)

How do you communicate? (1) If you can afford to send/bring someone (an ambassador) over to work with the other team at the beginning of the project, do it. (2) It is critical that your "go-to" has a daily meeting with the team. Select a method that allows each side to see one another. (webcam/Skype) (3) Have everyone use Skype (VoIP) and/or a chat client for one-on-one communications. (4) Keep a Skype connection open between the offices. (5) Use wikis or other collaborative solutions for common project information. (6) Stay away from email, unless it is for formal communication. Information is going to get lost along the way and it will take longer to clarify.

Remember to use parallel communication methods, not serial.

Starting Is Easy; Finishing Is Hard

I once saw (via video podcast) a wise man (Jason Calacanis) say "starting is easy; finishing is hard." When he said that, it was a moment of absolute clarity for me.  I'm not saying he verbalized the meaning of life.  He did state, however, what I've often conceptualized but was never able to verbalize.

What Jason stated in 6 words is what I've seen many colleagues struggle with.  Who doesn't have projects and tasks to complete and deadlines to meet?   I've tried multitasking, thinking it would make me more efficient.  I've tried using a productivity pyramid.   All I did was start more tasks, not finish more.  That's the key right there.  It doesn't matter how many things you start if you never finish them.

The solution to my past problems has been the use of kanbans, referring to them as information radiators.  These information radiators were large billboards strategically placed around the office so anyone could passively see the status of the current project.  You could see what the highest priority was, what was currently being completed, and what was being delayed.

I believe the key to those successes was in the ability to visualize our work.  Everyone knew exactly what they needed to complete and everyone else knew if it was getting done.  People were not allowed to go on to ancillary activities until their assigned tasks were completed.  Another important facet of the kanban, we limited our work-in-progress.  This forced-focus on limited tasks and constant feedback loop is very powerful and very productive.

If you would like to read my complete guest post at the Personal Kanban website, on how I visualize my work and FINISH it (don't forget the comments), just follow the [link].

How We Can Make Agile Work

I just read a really good post at PM Hut titled Agile Myths Debunked.  Sanjeev Singh listed 12 reasons people say Agile won't work on their projects and how they are misinformed.  His list included:Indiscipline, lack of planning, no documentation, no QA involvement, not for fixed bid projects... and the list goes on.

From my experience, organizations commonly get caught up in their project management processes.  I think they fail to realize, when saying they can not use Agile, the goal is to deliver value to the customer. As professionals, we should focus more on how it can work and less on why it can not.  I do believe Sanjeev's listed myths are the primary reasons Agile isn’t more broadly adopted in some markets.  I’ve sat in meetings and heard those same myths listed as though being read directly from his blog post. Only by educating clients and debunking these myths will we see more adoption.  I'm not saying Agile will work in every circumstance for every project.  What I am saying is you should never discount something unless you've at least tried.  Do your research and see where you can make it work.

Kanban for Lean Project Management

For those out there using Kanban for Lean Project Management, let me sing the praises of Zen.  Zen is a tool that applies the ideas of the Toyota Production System (commonly known as "lean" principles) to project management. Whether you already practice lean in your organization, you want to set up a lean process, or you just want an easy and effective way to manage your process, Zen will work for you.

Since I started using Zen back in July, my productivity increases has been astounding.  I used to think multi-tasking was the best way to deliver value.  I couldn't have been more wrong.  Instead, I now limit my Work In Progress to only 3 and only focus on 1 at a time.

Though I wrote about this product back in August, I wanted to give a formal product endorsement.  Getting started is free of charge. Once you begin using it on your projects, the cost is reasonable and scalable.  The Zen creators focused on what really matters, and designed an open-ended and easy to customize product.  They don't overwhelm you with metrics and force you to try to figure out what matters.  Instead, they track just a few high-value indicators such as cycle time and lead time.

If you've already implemented lean ideas in your organization, Zen can easily be used to replace a manual kanban board and spreadsheets, and has all the features you would expect to find in a lean project management tool.  If you think I'm a fanboy, you'd be right!  I love this product.  Check out www.agilezen.com

Mike Cottmeyer talks about scaling Scrum

On our current project, we have over 100 people across 14 Scrum teams.  The challenge?  How do you communicate between Scrum teams?  Well, that all depends. What are the dependencies between the teams? Though I could write a 1000+ word post about this, I figured I would just link to a short but informative video.  In it, you'll see Mike Cottmeyer talk about scaling Scrum and how you might have different types of scrum-of-scrums (the way you would communicate between Scrum teams).  Mike is a Product Consultant and Agile Evangelist at VersionOne.  You can read more from Mike on his blog, Leading Agile, or on the VersionOne blog, Agile Chronicles. I'm hoping if all goes well, we'll be bringing Mike to Washington DC to offer a few days of training.  I'm sure this will be one of the many important topics to cover.

How To Know When A Meeting Has Ended

I just read are very intriguing post by Ken Clyne on the Agile Blog, located at RallyDev.com. The post was about how problems can arise when people don't realize a meeting is over.  Ken offered one way to avoid the never-ending meeting is by having a clear signal that the meeting has ended. I could not agree more. Don't you just hate it when a meeting has ended, not everyone knows, and people just start to filter out of the area?  I've found myself looking at the meeting host and actually ask if we were done.  That is not a way to conduct a meeting.

Though I believe this applies to all meetings, the daily stand-up (daily scrum) really needs to have a clear beginning and end.  Though some may not agree with me, I like to use a visual aid like a big alarm clock.  Everyone sees the clock ticking away and know a very loud alarm is going to go off at an agreed upon time.  You see people get anxious if others are rambling on and the time is ticking away.  Think back to your youth.  Remember how you knew you were late for class because you heard that starting bell?  Remember how you knew you were dismissed from class because you heard that same bell? Let those years of conditioning motivate the team.  Though I like the visual queue, you should still say something to the team to close the meeting.

Unlike your school days and hearing your assignment is due Monday, I know I've closed meetings with So let it be written, so let it be done, Make it so and May the force be with you.

Link to the original post

Image: Pictofigo