Ian Burgess» Agile

Agile Product Development

Ian Burgess — Sat, 29 May 2010 12:19:31 +0000

The Slides from my recent presentation to the BNS on Agile Product Development.

Agile Product Development

View more presentations from ianburgess.

Agile Product Development is a post from: Ian Burgess

Basic Project Management with a focus on Agile

Ian Burgess — Tue, 17 Nov 2009 21:14:07 +0000

I have been giving this presentation as a introduction to project managment with a focus on introducing companies to the basic concepts of Agile. The presentation is aimed at PM Newbies and explaining agile to the managment teams more than the developers.

Agile Project Management

View more presentations from ianburgess.

Basic Project Management with a focus on Agile is a post from: Ian Burgess

SCRUM in Under 10 Minutes

Ian Burgess — Tue, 29 Sep 2009 21:57:09 +0000

This is possible one of the most concise videos on SCRUM from Hamid Shojaee of Axosoft.

SCRUM in Under 10 Minutes is a post from: Ian Burgess

No related posts.

Love this Agile Video

Ian Burgess — Thu, 17 Sep 2009 08:29:38 +0000

I just seen this video from “Global IT Consultancy” Thought Works it just made me laugh.

Love this Agile Video is a post from: Ian Burgess

Pair Programming- Software Development Learning Steps

Ian Burgess — Sat, 11 Jul 2009 19:46:06 +0000

The key to building a good software development team is to focus on the development of the staff. In most software teams many learning opportunities are removed to focus on the commercial or time-line of the project. Practices such as the two weekly demo or paired programming are drop to free up more time. Agile is full of learning opportunities which will improve the individuals, team and then the software they produce. lets look at benefits to learning and the software created by Pair Programming in more detail.

Pair Programming

Pair Programming is a software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it’s typed in. The person typing is called the driver. The person reviewing the code is called the observer or navigator. The two programmers switch roles frequently (possibly every 30 minutes). – Wikipedia

When I first saw this my initial thought as a project manager was this was the biggest waste of resource a software project could have. Mind you at this point I also believed that people could work 20 hours a day for weeks and shouting made people work faster (the ignorance of youth).

Now I am an advocate of Pair Programming for several reasons the most important being that it provides an excellent way to have experienced developers transfer knowledge and experience to junior developers, it is this knowledge transfer that interested me more in paired programming especially the changes that began to appear in the style of code and quality of the code that was being produced.

Knowledge Transfer

Most teams are made up of individuals from different backgrounds and with varied experiences so the potential for pair based learning is obvious, but most people don’t respond to either teaching or learning in a one directional knowledge transfer. As Pair Programming facilitates discussion on how the code is being written and in may cases opens discussions on principles, which as the developers delve into theses points they begin to evolve the way the both think.

Team Relationship

Possible the most interesting but far from surprising benefit is that the team progress through the normal team development process quicker (“forming, storming, norming and performing” Tuckman 1965) and are less likely to get stuck between the norming and performing stage.

The team dynamics is dramatical changed by this process as collaborative discussion is forced by the nature of two individuals working on the one peace of code. Supported by the close physical proximity to each other genuine relationship will be forced to develop as the interaction happens between the two paired individuals.

With in some teams I have seen the affect of pair programming ware the pairs are being continual rotated every day or so. This mixing of the team helps to deliver a bond between all the members of a new team.

Collective Code Ownership

One of the other advantages of Pair Programming is that it creates ownership of the code among the whole group, so it means that any single team member can change code, add functionality, refactor or fix bugs during development. This ownership of code being shared among the whole team leads to people being held accountable for decisions on how they have designed code, also this opening and discussions can lead to the development of the application being improved through debate.

Code Presentations

Not normal agile practice but I have found along with the other elements of pair programming making the developers present their code to the team, helps to transfer knowledge and ideas also spark conversations on deeper elements of coding.

Benefits

Along with the many benefits of that support the learning and development of the team their are many others that will help sell the concept of pair programming to the business:

With the mixing of pairs all the developers have a better understanding of the whole code.
New members of the team have a reduced period “getting up to speed”
Minimises dependences on individual members of staff
Massively reduces bugs in the code
It is harder to hide problems and easier to spot issues in the project

Their are many other benefits to pair programming I would strongly recommend that you try it if you are part of a development team.

Pair Programming- Software Development Learning Steps is a post from: Ian Burgess

Agile Retrospectives: Making Good Teams Great!

Ian Burgess — Thu, 09 Jul 2009 13:22:35 +0000

The importance of the retrospective cannot be underestimated it in many cases is the worst performed element of the agile practices. I am currently researching different project managers and facilitators retrospective practices.

I am currently documenting my thoughts on this but I during my research I found this video from Google Tec Talks.

Agile Retrospectives: Making Good Teams Great! is a post from: Ian Burgess

Nancy Van Schooenderwoert development in a safety critical environment

Ian Burgess — Sat, 27 Jun 2009 09:16:26 +0000

Clarke Ching from Agile Scotland invited the members of Agile Scotland to an event in Toshiba Medical Visualization Systems in Edinburgh, the speaker was Nancy Van Shooenderwoert. Nancy has been active in the Agile world for some time and is in many ways a evangelist.

The presentation was focused on software development in a safety critical environment, which is of interest to all of us as we all know the pain of software that has been developed with bugs in it.

The presentation was based on the core agile practices which help to remove bugs, continual testing, short iterations and continual review of team and design. Team dynamics and collective thinking were seen to be a major contributing factor to the dramatic decrease in bugs in software (there was a focus on the relationship between faults and function points).

The points that made impressions and I have been mulling over since the presentation were around the development of “Negative Stores” looking at faults/bugs that could be predicted and developing code in a way that removes the possibility of occurrences.

The other element was testing for unknown errors by flagging process and information that falls outside of the expected norms rather than just relying on tests that look for a specific issue. This is causing me to revisit much of my current projects testing plans.

Along with a great presentation, the trip back to Linlithgow, the discussion covered several points around the concept of metaphors and a subject that was touched on in the presentation Higher Level Learning. I would encourage you to read Nancy’s work Embedded Agile Project by the Numbers With Newbies

Once again thanks for the invite Clarke.

Nancy Van Schooenderwoert development in a safety critical environment is a post from: Ian Burgess

Agile Retrospective – Lessons Learned

Ian Burgess — Mon, 01 Jun 2009 12:33:43 +0000

The one phase that is most often neglected in agile development is the retrospective, fulfilling the same role as lessons learned in other methodologies such as Prince2. Only paying lip service to the retrospective will have noticeable effect on the delivery of the project it is in this phase that misunderstandings are outlined and process that have not went well are addressed.

Some Project Managers focus on this in a very structured way moving from one defined stage to the next, I have over time come to believe that a structure is important to focus the meeting but a strict agenda has never really achieved the best results. What I want to outline are general principles that should be included in any retrospective, remembering that each section will naturally flow together and it is the PM job to bring them back to the necessary stage and maintain relevance and focus.

Lets look at what a retrospective should include:

Review of work completed in the last iteration

Critical to getting an overall understanding of how the project is going, depending on progress it becomes easy to highlight areas where their are issues or hopefully areas where the team (includes the Developers, Project Manager and Customer) are excelling. It is important that this phase is not about apportioning blame but at looking at the root cause of any issues so that they can be explored in more detail later.

This often highlights areas such as communication issues, over-commitment of work, resource gaps and other areas.

Outlining of personal issues and team issues

Continuing from the previous stage we would discuss any issues that have arisen in more depth, this phase also allows team members to voice concerns and issues, but in most cases to put forward ideas to improve the process. It helps to view these based on their impact and effect on two areas the individual and team.

It may be something as simple as a team member requires more information than they are being given or a team issue to do with the availability of resources. The main benefit of the separation is that it quickly outlines which problems require a localized or individual change and can be dealt with separately from the more global team issues.

Discussion on what worked well

A point ware people discuss the process and situations that worked well see if there is any way to adapt for this to become a embedded part of the process.

Agreement on what is to change

An agreement is made on what to implement from the point raised earlier in the retrospective. In most cases it is easy to reach a consensus on as the team by this stage understand the importance of the points raised. It is at this point that individual issuers are dealt with separately with the main focus being the changes that will most benefit the team collectively.

Plan for implementing changes

Finally a plan is put into place to allow the team to attempt to embedded these changes, this may be a long process or simple someone taking accountability for a individual element or new process.

Although this is a quick and high level outline of the basics of a Agile Retrospective it by no means is inclusive and is set to become the first of set of article dealing with retrospective and lessons learned.

Agile Retrospective – Lessons Learned is a post from: Ian Burgess