Blog 4: Agile tasks lists, what does “done” mean in Agile?

Throughout a product’s creation it is shaped through every Sprint to reach a closer and closer state of completion. Being completed is a lot more then just finishing the backlog. Yes, your team implemented the extremely frustrating like button on your app, but does it work correctly? Are there any hiccups when the button is pressed? Does it crash your app? More importantly does the product owner like the button’s placement? Icon? functionality?

Perhaps one of the most important questions when evaluating whether your team is done would be is the product owner happy? Hopefully throughout the Agile process the Product Owner communicated what he wanted and went over the backlog and user stories with the team. This is to eliminate any potential surprises he may have when shown the completed work. If, for example, he never said anything about what type of icon he wanted for the app and the design team chooses a cool Viking skull picture for it. By chance the product owner is the one guy in the world who doesn’t like Viking skull artwork, the team is not done.

When the team is in development mode during a Sprint there are a number of things they need to be sure of to finish. There is the coding phase when the actual product is being developed. Then they move on to testing which insures that what ever they created works as it is suppose to and doesnt break someones computer or phone. Last, which I spoke of before, there is the confirmation by the Product Owner that he/she is happy with the end result. This might not give them the full shippable product but it moves them one step closer to that goal.

Just hopefully the team: Scrum Master, Product Owner, and other members have had enough discussions detailing what “done” means. It is enormously important that everyone knows what goal they are working towards to having a shippable product. What this means is that there has to be a set of rules which everyone knows and follows to determine when the team is done. Giovanni Cantone wrote, “Definition of done is a set of agreements that defines what done means…. Everyone on the team, including Scrum Masters and Product Owners, must have a common understanding of what done means.” In this way the team can all share in the understanding of their goals for the project and what they need to do to be complete.

       

 

Images Courtesy of:
1) http://www.xqa.com.ar/visualmanagement/2009/03/the-done-tag/

2) http://instantdane.tv/blog/to-do-list-paper-or-digital

Ambler, S., & Holitza, M. (2012). Agile For Dummies®, IBM Limited Edition. Hoboken, NJ 07030-5774: John Wiley & Sons.


Cantone, G., & Marchesi, M. (2014). Agile Processes in Software Engineering and Extreme Programming. Rome Italy: Springer.

Blog POST 3: What is an Agile Sprint Retrospective?

Sprint Retrospective

Save those tears!

The team successfully bangs out their Backlog (see previous blog) after pulling a week’s worth of 15 hour days. Time for a break? Not yet! After the sprint, while everything is still fresh in their weary minds, the developers, Scrum Master, and product owner get back together for a Sprint Retrospective. During the Sprint Retrospective the team addresses what they should keep doing, what they should stop, and what they should start.

First, what should they keep doing? That is what the team nailed so well that they should keep doing throughout the remainder of the Sprints. This could be something easy like great communication during the Scrums (quick 15 minute meetings). Or it could be something much different, like pizza on Fridays for improved moral. In reality what should be continued should be quite easy to see for the team. Something had to work for the Sprint and that something should be continued throughout the project length.

Next is what should stop doing. What is the team doing that is hindering them during the Sprint? Chris Mann and Frank Maurer write “During the third sprint retrospective both the customers and developers agreed that there would be no more extended sprints as they had caused too many problems in terms of the developers not knowing what they needed to do.” This example illustrates the power of a Sprint Retrospective. The team is forced to discuss their work and are able to quickly find a solution to their woes.  In other development models the team might not stop and analyze their progress till much later in their development cycle.  This, of course, would cause unnecessary trouble for them because they would keep doing things that are hurting them. During my illustrious career in retail how I wish we had something like this. It could have saved many long days and un-needed angst.

The third and last idea that the team talks about during the Sprint Retrospective is what the team should start doing. Should they start talking more? Should they start having beer on pizza Fridays? After a successful Sprint there might not be much that the team needs to start doing, they are already doing it! But if the team is left in defeat then they really need to collect their thoughts and try something new.

A Sprint Retrospective is a key piece for the Agile Development Method. Through it, a team can explore their Sprint and come up with ideas on how to improve themselves. Everyone takes part in the Sprint Retrospective, product owner, Sprint Master, and the development team. Together they can come up with ideas to continuously improve their work, moral, and speed of completion.

Image courtesy of :  http://www.we-heart.com/upload-images/lichtensteinaretrospective1.jpg

Ambler, S., & Holitza, M. (2012). Agile For Dummies®, IBM Limited Edition. Hoboken, NJ 07030-5774: John Wiley & Sons.

Mann, C., & Maurer, F. (n.d.). A Case Study on the Impact of Scrum on Overtime and Customer Satisfaction. Retrieved from http://ase.cpsc.ucalgary.ca/uploads/Publications/MannMaurerAU2005.pdf

Blog 2: The Agile Team and what is a Backlog? What are they for and why are they important?

Backlogs

 

Every good design has to start somewhere. In Agile that beginning comes from User Stories and the creation of a Backlog.  Dean Leffingwell in his book “Agile Software Requirements: Lean Requirements Practices for Teams, Programs” describes a backlog as the sole source of work for the team. Meaning the team bases everything the need to accomplish off of the Backlog. Which also means that the Backlog is one of the first things that needs to be completed before any development can begin. With that said let’s explore where the Backlog begins.

When a team gets together they begin gathering ideas together for their Backlog. Many of their most important ideas are pulled together from User Stories. A User Story gets the developer in the mindset of the people who would be using the software. A very basic User story: “As a user of product X I would like to be able to quickly save my process by a keystroke”. This is turn would be placed on the Backlog to code in a simple keystroke, say F5, to save the current state of their program. This is a very simple example but as you can see it gets the designers in the head of a user which could be tremendously powerful.

Although backlogs are great they should not be held accountable as if they were the Ten Commandments. Dean Leffingwell explains that developers should not be held hostages to their backlog. He says, “If the backlog you have isn’t the one you need to meet the release objectives, ignore the sunk costs and flush it!” What this really is that a developer should follow their Backlog but if they have met their current objectives but still have a few items that haven’t been completed, let it go. The costs start mounting in trying to complete every single objective, especially if other more important items in the Backlog have taken longer than first thought.

A product Backlog is an organizing tool for developers to use to stay organized and focused on their goals. The Backlog is taken directly from User Stories and are executed during Sprints. Sprints are the development times of the product design cycle. Different Sprints would have different goal outcomes depending on the complexity and difficulty of the backlog. For a personal example I spoke with a designer of a popular text app on the IPad (name withheld for reasons). His most recent Sprint was focused on a single item in the Backlog. That was to fix the UI that was left inoperable by the update to IOS 6. His Sprint was not completed until the UI was completely back to normal.

Image courtesy of: http://www.redminebacklogs.net/en/usage-product-owner.html

Leffingwell, D. (2010). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.

 

Ambler, S., & Holitza, M. (2012). Agile For Dummies®, IBM Limited Edition. Hoboken, NJ 07030-5774: John Wiley & Sons.

Blog 1: What is Agile and what are user stories?

CODE AND FIX

Code and Fix
One of the original concepts for software development was the Code and Fix or Big Bang. In this style of development a person or team would write some code then fix what was wrong. This is perhaps the way many people start coding as it is simple is nature and lacks real thought or study to accomplish. Code and Fix’s biggest advantage over its peers is that you begin to develop right away. Much in the way a beginning CS major will face their homework. Although, this “advantage” is also one of the biggest disadvantages of using Code and Fix. Software for the real world is complex. A designer has to worry about security, multiple platforms, and making sure their actual software runs! Code and Fix is in no way a logical method to develop anything besides “Hello World”, and that maybe pushing it depending on the complexity required.

WATERFALL

Following Code and Fix, Waterfall was the next major software development style to be used. Often called the classic development cycle, Waterfall cleaned up the design process. In waterfall six major steps are rigidly followed. First are the requirements of the software. This would entail the purpose of the software and its platform needs. Second is the design of the architecture of the program and its UI. Third is the actual coding of the program. Fourth is the integration of the software into its environment so that it may be tested which is number 5 on the list. Six which is the last step is deployment. Deployment comes after the software is found perfect enough for the end user. The software will not be completely finished but that’s what updates are for right? The biggest hurdle teams run into when developing using the Waterfall method is that it is extremely difficult to go back a step. Each step is thoroughly documented and trying to back would require a lot of re writing and editing that on a large scale is not realistic. Leffingwell writes”… but in any case it’s clear that misunderstood and changing requirements had a huge impact on project success…” (Leffingwell).  This lack of agility to fix something in a previous step leads us to our last development mythology.

AGILE

Agile is so named because it is nimble in the development of software. Although Agile has a set of steps that need to be followed for a successful product it does not punish a team if they need to change an idea or design. In Agile a team is able to nail down exactly what they want in their software in what is called User Stories and backlogs. The team goes through a series of Sprints to complete their backlog. At the end of a Sprint a Sprint Reflection is performed so that the team can discuss things they liked and didn’t like during the Sprint. All the while this is happening the team meets each morning for a Scrum, so that they can discuss what is happening and to make sure that everyone knows their rolls and how to accomplish their tasks. In Agile the developers use quite a ingenious way to come up with ideas for their product. They create User Stories which are told in the perspective of the user. A sample User Story would be “As a user of X program, I would want to know how many hours I spend doing Y”. The Team then uses this to create a Backlog for them to work on.  Scrums, Product Backlog, and Sprint Reflections may sound foreign now but throughout these blogs I’ll be delving more in depth into each topic.

A visual interpretation of Agile vs. Waterfall

Images courtesy of: http://sqtc.wordpress.com/2012/01/04/software-development-life-cycle/ 

http://savaged.wordpress.com/2010/01/23/mix-agile-development-with-waterfall-project-management-and-get-fragile/

Ambler, S., & Holitza, M. (2012). Agile For Dummies®, IBM Limited Edition. Hoboken, NJ 07030-5774: John Wiley & Sons.

Leffingwell, D. (2010). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.