CONSCIRES AGILE PRACTICES

Agile Kuizu – Beta

By Jeena / Filed under Agile, Scrum / May 6th, 2013

Agile enthusiasts!

Think you know all there is to know about Agile?

Take this small quiz – and see if you are right!

We have compiled a small quiz for you – we call it Agile Kuizu Beta.

What’s Kuizu? Click here and you’ll know.

Follow this blog and be notified whenever we post informational articles / quiz / etc. for you.

Have something interesting to share with us? Go on, we’re listening! agile@conscires.com

What Agile Means to Me – 13 Things!

By Bachan Anand / Filed under Agile / March 7th, 2013

It is around five years since I first heard and experienced Agile and Scrum. Here’s a little peek into my Agile journey:

 
Agile for me ….

• …. is to work in a more humane way.
• …. has the potential to create a working environment that is rooted in trust, transparency, and results.
• …. is about getting 80% of the people doing 80% of the work, rather than 20% of the people doing 80% of the work.

• …. is about giving yourself the permission to stop doing ineffective things.
• …. is about allowing yourself to make mistakes, but to learn from them.
• …. is about believing that we can all be creative when we work as a team and that creativity is not just for the elite.
• …. is about creating more leaders in a team.
• …. is about an expert stepping back so that others can come along, contribute, lead, and become experts themselves.
• …. is about creating a work-life where we don’t need to wait for evenings or weekends to do the things we like.
• …. is about accepting the reality that growth is not steady and that setbacks are a part of that growth.
• …. is about accepting that success happens not because we focus on it, but because it is a combination of action, luck, and belief in what you do, as well as God (as each person understands God).
• …. is about accepting that people can be more effective as a group than as individuals.
• …. is about accepting that to err is human and to forgive is also human!

The aforementioned may or may not be the ‘Agile’ as in the Agile Manifesto, but they are a reflection of my Agile Mindset.

Please note: I have used ‘Agile’ and ‘Scrum’ interchangeably.

Scrum with a Baby

By Lalita / Filed under Agile, Inspect & Adapt, Scrum / December 4th, 2012

My husband and I were recently blessed with a charming little baby girl! As first-time parents who’ve not even had the experience of baby-sitting other people’s kids, we quickly realized that we have a LOT to learn and re-learn. Our baby was inadvertently FORCING us to re-think how we had been performing even the most routine tasks. And here’s the thing with being (new) parents: We are eager to get things right and perfect ASAP. (Come on, I’m sure even the seasoned parents would agree that they would have liked to have gotten some things right very early on). So, here’s my take on learning and re-learning quickly: Scrum!!

If you think about it, all of us are wired with Scrum. We make PLANS, which we put into action, and then we sometimes REVIEW and RETROSPECT on what we have done. If we are disciplined, we implement what we have learned so that we perform the same task with greater efficiency the next time around.

While this is common sense, I feel that if we actively review and retrospect on our experiences and then implement what we have learned, success is sure to soon follow!

P. S. Here are some of the things that our baby taught us: Old-wives’ tales can sometimes be genuine home-remedies, that one extra set of clothes for a quick outing is not enough, that it is better to just agree with those offering advice (even the unsolicited), and most painfully, that mothers can kiss continuous and undisturbed eight-hour sleep goodbye!

The Power of Visualization

By Bachan Anand / Filed under Agile, Scrum, WORK is GOOD / November 5th, 2012

A couple of months ago, a friend asked me for directions to my house. I sent out a detailed email, listing out the landmarks he should look for, the turns and exits he should take. My directions were impeccable; nonetheless, he landed up two blocks down the street. The next time I had to give directions to another friend, I sent out a hand-drawn map that I had scanned and kept ready. There was nothing new in it that I did not mention in my first email, but this friend found the way to my house without any confusion.

The impact of visualization can be illustrated with another real-life example. If you tell a small child that ‘an apple and a tomato have the same color’ he would probably blink. Instead, show him an apple and a tomato and then tell him the same, he would immediately get what you’re trying to say. It is an inherent habit that we all possess – the ability to grasp and recollect faster when information is demonstrated rather than explained verbally.

We see it in action everywhere, yet we close our eyes on its significance. We can apply it on any task that consists of a set of activities. For example, recently my wife and I utilized this method to plan and manage our monthly expenses. The exercise turned out to be quite effective and fun at the same time!

If we translate this concept to work, every project or activity that involves a set of steps can be further broken down and made into visual sequence. For most of us, reading a lot of continuous text, even beautifully bulleted ones, requires a lot of effort – that could as well be the one reason we put it for later. When there is a pictorial representation, the effort required is less. The pictures, colors and shapes jump out of the screen and impress themselves right onto our brain. It is next to impossible to ignore or forget them! It also has the added advantage of providing clarity on the complexity of the task in question. With clarity come determination, focus, the ability to prioritize and remove what is out of scope.

It is a fact that the tougher a job looks, the more lethargic we become. Even the easiest tasks can be made to look complicated by converting them into ten-page documents. On the other hand, illustrations, with colors and shapes thrown in to distinguish between their priority and status, give the impression that it is easier to achieve and help to keep the goal firmly in mind.

Taskboards, story maps and vision boards are visual depictions of a project. With one of them at hand, there is no fear of losing sight of the target or diverting from the path. They also show how close the work is to the end, and as such, act as motivators for the team.

The advantages of having a visual taskboard are many-fold.

For an individual, breaking down of a bulky task to smaller chunks, having a visual indicator of progress and setting aside each completed activity are steps that bring him closer to the target. The visualization gives a clearer picture on how much work is pending, what has been completed and how close we are to the end.

For the team as a whole, visualization creates a common understanding of the goal, gives clarity about the many pieces involved in solving a problem and helps each individual pick up tasks they can complete.

For the project, this method of depiction ensures that all the aspects are captured properly, and it avoids concerns of never getting around to address some of the items in the list.

From the leadership point of view, it is perhaps the most effective and visible way of communicating the mission of the company and rallying the overall organization around the company’s vision. The leadership, in turn, gets a glimpse of the progress that the teams make towards the completion of goals.

To make all these possible, it is essential to keep the visual tool clutter-free and up to date so as to make the most out of it. Once it is created, it is easy to weed out redundant or irrelevant data which may create a negative impact.

Vision is indeed the most powerful of all our senses. The easier we make it on our eyes, the better it engraves itself on our brain. After all, there is a child in all of us!

A Potentially Shippable Product: What Does It Mean To You?

By Lisa Montaño / Filed under Agile, Scrum / October 19th, 2012

I teach an “Introduction to Scrum” class a few times a month, and many students come with the expectation of learning how to implement Scrum within their organizations by the end of the day—an expectation that I have no hope of fulfilling. Every organization is different, and delivering a valuable piece of working software at the end of each Sprint means something different depending on the organization and the business. Because Scrum is a framework for working that leverages principles and ceremonies rather than adherence to a specific methodology, organizations must determine how to leverage the principles within their own context. A perfect example of a Scrum concept that has to be made relevant to the individual organizational context is the “Potentially Shippable Product”.

The signatories of the Agile Manifesto say that Agile values “working software over comprehensive documentation”, that a team’s highest priority is to “satisfy the customer through early and continuous delivery of valuable software/products”. In other words, teams should strive to deliver a “Potentially Shippable Product” at the end of every Sprint – working software that can be evaluated by customers and that has some real business value. Whether a team is working on a single-team project or a multi-team effort, creating in-house software or a product for re-sale, using Scrum as a product development tool requires the organization to determine and define what Potentially Shippable Product means to them.

The product owner and the team will determine what constitutes a potentially shippable product, in meaningful chunks of features that the customer will be able to provide feedback on during the product review and demonstration. In his book “Succeeding with Agile” (2010), Mike Cohn says:

“To fully define potentially shippable would require knowledge of the domain and application that only the team, including its product owner and ScrumMaster, will have. In fact, one thing any new team should do is discuss and agree on a “definition of done” that defines a potentially shippable product increment appropriate for its environment (p 261)…

Cohn makes two distinctions in his discussion of a Potentially Shippable product. First, he mentions the need for the organization to agree on a “definition of done” that satisfies the needs of the domain for calling working software complete. So, a team needs to determine its organizational working agreements and quality requirements before a product may be released into a production environment or sold in the marketplace.

Some of the criteria that an organization may use to qualify a “potentially shippable” product as done include:

• Software code has been designed
• Software code has been written
• User interface has been designed
• Unit testing is done
• User Acceptance testing is done
• Integrated within and between teams

Once the team agrees on the definition of done for tasks, product backlog items, and sprints, then the work of the sprint can commence and team members can use the “definition of done” agreement as a guide for completing their individual and collaborative tasks.

Delivering something observable, meaningful, and valuable to the customer or end user is the next point that Cohn makes in his discussion of a Potentially Shippable Product:

..The intent is that each sprint should deliver something of immediate value to users or customers that they can see. Because one of the benefits of working in sprints is the ability to generate feedback from users and customers at the end of each sprint, a team will get better feedback if at least some of the work done each sprint results in features that users can see (p 263).”

So not only does the team need to deliver working software, but they also have to deliver something that the customer will perceive as useful and valuable. The underlying assumption here is that the team, product owner, customer, and stakeholders have collaborated together to define what “valuable” means in the context of their product and business.

One of the most challenging transitions that new Scrum teams will make is to shift the focus from project phases and milestones, to delivering an emergent product over time. Scrum delivers products incrementally, beginning with basic features and functions, and with iterative cycles of development and feedback, evolves into a more robust, fully functional product that serves the customers’ most important needs, delights customers, and inspires them to become not only repeat customers, but product evangelists.