Tony Askew's blog

Being Agile has its advantages…

Once you’ve adapted a plan to implement agile, you immediately have an advantage over the competition.
Leveraging the value of agile will improve your business delivery times, limit risk, and improve the ability to adapt to changes. Progress is measured incrementally by the production of working software which increases the overall business value. Product/unit testing in the early stages of the product life cycle also allows faster discovery of potential bugs or for the discovery of new code that may improve the efficiency of the product. Neither of which can be achieved using waterfall or other none agile methodologies.
Agile strategies allow development teams to experience a lightweight process that supports a focus on the rapid delivery of value. Organizations experience a significant reduction with the overall risk associated with development. Meaning business value is maximized not only throughout the development process but incrementally as well.
Additionally the customer will witness the transparency provided by agile development teams, and will realize the immediate benefits provided by daily real time updates. Above all organizations are beginning to see that agile methods turn out software at not only a faster pace, but doing so bug free.
The agile advantage!? Getting to market faster with an improved product….

SCRUM BOARD,

For my newest project; Security remediation plan. Mostly a simple task list, but also some discovery involved as well.

The Psychology of Agile.....

I’ve noticed the biggest challenges of becoming agile are in the methods and manner of which a company decides to adapt agile methods for project management. First know, “agile is something you are, not something you do”. Once this can be distinguished, then becoming agile will be easier.

A company cannot force agile into its current culture, but it must allow its culture to evolve into an agile state. Agile is a state of mind, a way of thinking and a different project mindset. Agile doesn’t require, but it demands adaptability. It demands a de-structuring of current none agile methods. You can’t have a daily scrum, yet continue using waterfall methods and expect to be agile. You’ll never realize the full potential of being agile. I say this because I’ve seen it happen over and over again.

To become agile it is best to seek out training, hire an agile coach, and start small. Never start with agile on an enterprise initiative. Use a smaller less impacting project first so you can get the true feel of the agile culture.

Remember, “agile is something you are, not something you do”.

The Daily Scrum....

Held daily

15- Minutes (no longer, otherwise it’s not a daily stand up)

Not for problem solving (if there are issues that need to be addressed hold a separate meeting)

Is not a status for the scrum master

It’s commitments in front of peers

• Hold the daily scrum in the same place at the same time every work day. The daily scrum is best held first thing in the day so that the first thing team members do on arriving at work is think of what they did the day before and what they plan to do today.
• All team members are required to attend. If for some reason a team member cannot attend in person, the absent member must either attend by phone or by having another team member report on the absent members status.
• Team members must be prompt. The scrum master starts the meeting at the appointed time, regardless of who is present. Any member who is late pays Rupees 50 to the scrum master immediately.
• The scrum master begins the meeting by starting with the person to his or her left and proceeding counter clockwise around the room until everyone has reported.
• Each team member should respond to three questions only:

1) What have you done since the last daily scrum regarding this project?

2) What will you do between now and the next daily scrum meeting regarding this project?

3) What impedes you from performing your work as effectively as possible?

• Team members should not digress beyond answering these three questions into issues, designs, discussion of problems, or gossip. The scrum master is responsible for moving the reporting along briskly, from person to person.
• During the daily scrum, only one person talks at a time. That person is the one who is reporting his / her status. Everyone else listens. There are no side conversations.
• When a team member reports something that is of interest to other team members or needs the assistance of other team members, any team member can immediately arrange for all interested parties to get together after the daily scrum to set up a meeting.

Scrum board close to DONE.....

New with Scrum; start small!?

One of the biggest mistakes I've seen companies make when implementing scrum for the first time, is going to big, too fast. While the concept of scrum is simple, it can often times be very difficult to implement in an environment that is formerly C&C.

Although all projects bear significance to the business space some projects carry more relevance than others. My suggestion would be to start with a project that has minimum visibility and minimum impact to the business space.

My suggested approach is actually starting with Kanban. The process is simple; you have a task list, a WIP, (work in progress) and a DONE column. That is kanban in its simplest form. It is a three column approach to oversimplified development. As you progress and successfully close projects using this method, it will be easier to move on to more complicated development projects that require more time, and a larger team. Although most kanban boards are usually only three columns, you can customize your board to include additional columns I.E. testing, development, review, design and so on.

One of the more interesting aspects of a kanban board is the variety they come. Each is as unique as its originator of scrum master running the project. There is a wide range of paper media from post-its to index cards, to simple pieces of paper and are applied to the board by their own adhesive properties or by tape or even stapled.

If you or your company is thinking about Agile, starting with kanban would be a great way to get a feel what it takes to become a high performance team.

It all started here........

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

Principles behind the Agile Manifesto

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

To support the Manifesto and become a Signatory....

http://www.agilemanifesto.org/sign/signup.cgi

The Value of Transparency

One of the more defining attributes of Agile is its transparency. While those in the world of agile/scrum view transparency as a tool to successfully identify potential issues early in the development cycle, for agile newbie’s it can be a daunting visualization of oops, we have a problem.

For agile practitioners and enthusiast transparency offers the opportunity to create and quickly adapt (yet another agile attribute), when needed.

One of the advantages of transparency is it lends itself to clear business results, I.E. working software delivered at regular intervals.

Transparency also helps drive the openness of communication and information; thereby improving ROI, Making the continuous flow of values the focus.  

More to come…………………….

Are we over processing Agile? Is it me or have there been a myriad of discussions from individuals implying that maybe Agile requires more documentation, more structure!?
Before going further, I will stipulate that the culture from business to business varies, but shouldn't the basics and fundamentals of Agile/Scrum remain the same? Anyone whose read Ken Schwabers book on Agile Project Management with Scrum knows that Ken suggest two fundamental steps,
1. Keep it simple
2. Use common sense

I’ve used Agile/Scrum on both small and enterprise size initiatives and not once have changed my approach or method.

Agile/Scrum was developed to get away from the C&C, and constraining environment of conventional project management, yet there seem to be many who suggest changes or additions need to be made. Isn't that going backwards?
Anyone else noticing this trend?

In the world of Agile, Scrum and Kanban are both extraordinary tools for spinning up, running and closing a project. Both methodologies are effective and adaptable. However, the art of combining the two is a method I've used with better than expected results.
The following case, from Lithespeed explains the approach of combining Scrum and Kanban....

http://lithespeed.blogspot.com/2010/06/kanban-for-service-desks.html