Agile/Lean Product Development and Delivery – Mastering the Art of Change

by Russell Pannone (2009-09-23)
Rating (0 ratings) read comments

Mastering the “art” of agile/lean systems and software product development and delivery requires you ask yourself, “Do I really understand both the technical and non-technical imperatives associated with this undertaking”?

This article takes a look at mastering the art of agile/lean system and software product development and delivery; focusing on change.

What's Going Right Around Here? Using AI to Improve Your Agile Requirements Process

by Ellen Gottesdiener (2009-01-24)
Rating (0 ratings) read comments

Instead of focusing on the problems, focus on what works. That is the simple premise of “appreciative inquiry.” In this week’s column, Ellen Gottesdiener explains how to help your team focus on the processes that work by outlining what should be included in your appreciative inquiries, in order to make more positive organizational changes.

Say It Out Loud!

by Alex Rosiu (2009-01-09)
Rating 5.0 out of 5 (1 rating) read comments

Communication is one of the key factors that drive teams towards their goals, making possible the exchange of ideas, plans or problems. It is therefore crucial to do it efficiently, while keeping in mind that you’re still talking to humans and not some kind of information processing machines.

How Agile Practices address the Five Dysfunctions of a Team

by Tathagat Varma (2008-12-30)
Rating (0 ratings) read comments

Since times immemorial, ideas, objects and experiences of grand stature and lasting economic, social and emotional value have been created by men and women working together in teams. Granted that some extraordinary work in the fields of arts, philosophy and sciences was done by truly exceptional individuals, apparently working alone, I suspect that they too were ably supported by other selfless and unsung individuals (in the backoffice, perhaps) who all worked together as a team. Right from the great wars, social upheavals, political resistance, empire building, freedom struggles and forming of nations and protecting its borders to the creation of majestic wonders such as Pyramids, Taj Mahal, Eiffel Tower, Statue of Liberty, Sydney Harbor Bridge or the London Eye and many more, each one of them owes its creation and existence to teamwork. Of course, the scope of teamwork doesn’t exclude simple, mundane and everyday things that are extremely important even though they never make a headline: an activity as routine as tilling the fields, or planning a picnic or even a family function, all involve a team.

With such profound impact teamwork having on our everyday lives, it is only natural to expect that output of a team is directly impacted by the quality of its teamwork. Unfortunately, this doesn’t happen by having right intentions alone, or by leaving it to chance. Quite often, it doesn’t even happen ! Quality of teamwork is impacted by various factors such as motivation levels of individual team members, levels of trust among team members, clarity of purpose, uniform understanding of the goals, lack of resources, poor communication among the team members, and so on. Thus, it comes as no surprise that appropriate investments must be made to make the team click. However, most often, team dysfunctions affect a team’s performance seriously jeopardizing its ability to perform effectively, any state of art processes or tools notwithstanding. Most software managers lack the ability to detect such deeper sociological smells, thus are unable to deal with its impact. Any superficial response to such problem only makes the task harder to deal with.

In this article, I have analyzed the team dysfunction model proposed by Patrick Lencioni in his wonderful book, written in the form of a fable in a business setting, The Five Dysfunctions of a Team – A Leadership Fable. In his model, called The Model in the book, he has identified five dysfunctions of a team that affect team performance. These five dysfunctions are not really independent, but interrelated to each other, and build on top of one another…

What's in it for Me?

by Alex Rosiu (2008-12-01)
Rating 5.0 out of 5 (1 rating) read comments

Change is one of most people’s greatest fears, and therefore introducing it usually meets significant resistance. We all tend to stick to what we know, as we usually get quite good at what we’re used to do. Thus, when being faced to important changes in our lives, work or habbits, we will most probably react by trying to reject them, unless we really understand the benefits.

Forbidden Words

by Alex Rosiu (2008-10-03)
Rating 5.0 out of 5 (1 rating) read comments

Communication is part of our every-day life, it is the key to all our relationships, personal or business, good or bad…

Selling Agile: Building People's Commitment

by Kelly Waters (2008-02-21)
Rating 5.0 out of 5 (1 rating) read comments

Building people’s commitment to anything new, or to any significant change, is something that takes time and happens in distinct stages…

Track progress with a daily burndown chart

by Kelly Waters (2007-11-07)
Rating 5.0 out of 5 (1 rating) read comments

“oh dear, it was going so well”...

How to implement Scrum in 10 easy steps - Step #5: Create a collaborative workspace

by Kelly Waters (2007-10-16)
Rating 5.0 out of 5 (1 rating) read comments

A place for visibility and collaboration…

With Agile practices a distributed team is so far yet so close

by Priyanshu Goyal (2007-07-17)
Rating 4.0 out of 5 (1 rating) read comments

With Agile practices a distributed team is so far yet so close. It is actually one team

A typical distributed development team works on a piece of software or sometimes entire system based on a set of requirements passed on to them either from the client or a team of guys working on a part of the same system onsite. This is generally referred as plan-based approach and the requirements are mostly document-driven.

They work day-in and day-out on these requirements for a good period of time without getting much chance to interact with the customer, or may be even with the team onsite making them feel really away from the where the action is.

They work and they deliver but is it the right stuff? How does a non-agile distributed team know that they are going to deliver sometime which is needed by the customer? How can they get the confidence that they do understand the project requirements? (Although told and documented but we all know how rarely it works that way)

Pretty sure when people came up with agile practices, they must have never thought they are really helping a distributed team come and take up a place at the center of the stage along with onsite team or may be they are not two teams but one with agile! Here is how agile supports one team feeling.

• Stand-up daily – Every member of the team be it onsite or offshore go through this at the same time together each day, thus very well aware of the current status of the project, who is doing what, what are the risks/impediments/issues and most importantly gets a feeling of what they are doing really matters a great deal for progress of the sprint. Many a times even the offshore team gets a chance to see the real stakeholders participate in such meetings as chickens

• Every one is an owner (Collective ownership) – The onsite and the offshore teams have a collective ownership of the code and deliverables and help them get a feeling of one team working towards one goal in real sense.

• Team participating in effort estimates – Whole team gets a chance and opportunity to estimate the stories and organize it and also to blame themselves if things do not go right. A progress/sprint burndown chart is good visible representation of how the team is doing during the sprint for the team as well as for the customers.

• Frequent check-ins and continuous integration – XP forces a team to do very frequent check-ins and with a good continuous integration process in place ensures a report is generated of good stuff and wrong doings of a team. This may impact the work of any member onsite or offshore in real time. There is no need for merging offshore and onshore pieces as they share the common code base.

• Automated Tests – Automated acceptance tests is a way to specify, clarify and verify requirements with a lot of team and customer involvement.

• Showcase what you have (Small releases, end sprint demo and sprint planning meetings) – Distributed teams gets to interact, clarify doubts, ask for feedback and do an exhaustive retro inspection very frequently as part of these meetings because of immediate access to the customer.

• Split it on functionality – Agile practice advocates that each team work on different pieces of functionality and not necessarily on different activities. So the distributed team is involved with important aspects of software development life cycle such as analysis and design as well.

• Communication is all what matters (Collaborative tools) – One of the value of XP is communication and with tools for VOIP, instant messaging, issue tracking and Wiki (confluence) frequent communication and collaboration is very much possible with the client and the onsite team. Good and frequent communication provides a platform for emerging requirements, technology and team capabilities.

• Taking it to extreme – Though difficult, distributed pair programming is possible or may be pair for a few time and then disperse. It is taking the one team feeling to the extreme.

• Dealing with reality and not artifacts – An agile distributed team feels that they are doing something for real and not just going through an archaic process of creating artifacts/deliverables one after the other. An agile distributed team knows a lot about what is actually happening and most of the times aware of how are they doing, in catering to client requirements because of short iterations build on the principle of inspect and adapt.

So all in all Agile principles, practices and tools can help to address the issues of distributed development to a very large extent bringing them closer to the onsite team.