Agilification

Greg Williams from Atomic Object offers some helpful insights regarding the "agile" movement.

Practicing ‘Agile’ Doesn’t Necessarily Make You ‘agile’

Tags: agile, philosophy

If you do a search for the phrase “is this meeting necessary” you will find a pile of links that give helpful questions to ask when calling a meeting. I believe we should be asking similar questions before sending email messages. In that spirit, I present to you the following...

Is This Email Necessary?

Team members often send emails with the desire for quick and simple communication. However, many email messages actually create inefficiency due to interruptions, context switching for the recipient, and a lack of clearly defined expectations. Sometimes deciding not to send an email may be the best use of everyone’s valuable time. Here are some things to consider for every email message - before either writing and sending, or discarding.

• Is there a clear purpose for the email? Does this message provide enough information for the recipient to take a specific action? Or will they be left with either nothing to do in response, or confusion about what is expected of them?
• Should I send this email now? Is it worth the other person’s valuable time to be interrupted with this information at this moment? Is the information in the message urgent to them, or only to me?
• Is there a better alternative? Do we have another system in place for tracking/storing this information and helping us make decisions? Is email really the correct tool for communicating this information?
• Am I sending this message to the right person? If sending to multiple people, are they the right audience? Can the recipient(s) take appropriate action? Will I potentially be causing a needless interruption?
• What will happen if the email is not sent? What will be accomplished in sending this message? If the recipient would say “nothing would be missed” then you have your answer, which should lead you to either discard the message, find another way to communicate/store the information in it, or postpone it until you have clarity regarding the previous questions.

Tags: agile, communication

Brandon Durham explains why:

http://37signals.com/svn/posts/2922-whatever-interests-you-naturally-is-the-most-important-thing-to-work-on-

Tags: agile, process

James Turner explains the importance of being truly agile, rather than making your team beholden to process for its own sake.

http://radar.oreilly.com/2011/05/process-kills-developer-passion.html

Tags: agile, tdd, scrum, insanity, patterns & practices

Tags: jobs, hiring

We just finished updating the Lotpath Software Development Process page on our website.  In particular, we spent time reflecting on our philosophy of software development and the way our company operates generally.  This was a great opportunity for us to reflect on our stated values and to evaluate how well we align with those values.  Of course, alignment is an ongoing, iterative process.  For now, we have put our stake in the ground, choosing to define ten elements that form our philosophy.

The Lotpath Philosophy

• Be Agile. Adapt quickly to changing circumstances. The strong may survive, but the agile will thrive.
• Focus on Business Value. Deliver working software that provides business value. Do this early and often.
• Only Deliver Business Value. Avoid adding bloat to software projects such as features that are never used or documentation that is never read.
• Avoid Analysis Paralysis. Create just enough requirements, specs or documentation to gain shared understanding of business value.
• Streamline The Feedback Loop. Use automated testing and continuous integration practices to provide a continuous, automated feedback loop.
• Fix Defects First. Give software defects higher priority than new features and fix them first.
• Relish Honesty. Seek the truth. If you need help, ask for it. When you make a mistake, own it, learn from it, and try not to repeat it.
• Embrace Change. Technology changes every day. If you don't change with it, you become a relic of the past.
• Keep Learning. Survival in the world of technology requires constant learning. Learn something new every day.
• Have Fun. Express your creativity, try new things, learn from others, and enjoy doing it.

What elements form your software development and project management philosophy?  What would you add to this list, or remove from it?  How do you increase alignment between stated values and actual realities?

Tags:

Check out Robert Schultz's opinions on the matter.  

Tags:

Lately I'm hearing a lot about agile "processes" and teams that claim to be adopting an agile "methodology".  This sort of language speaks as if certain structures and procedures can be adopted which will make a team agile. This thinking is misguided at best, damaging at worst. When Kent, Bob, Ward and the other 17 "Apostles of Agile" crafted the Agile Manifesto, they did not publish a list of procedures or processes.  Instead they provided a set of values and priorities.

Are you part of a team that is striving to be agile?  If so, ask yourself, what is the primary driving force behind your efforts?

• Structures
• Procedures
• Processes
• Methodologies

or

• Values
• Priorities
• Principles

Do we need structures and procedures?  Absolutely! They are the context in which we perform concrete actions in order to fulfill the values and priorities to which we are committed. However, it is the ability to adapt these structures and procedures that makes an Agile team. When methods and structures are rigid and unchanging, agility has ceased.

Agile is not a process, but it is about how we create, shape and adjust our processes. The real question to ponder is this: "Do current structures, procedures and metholodogies enable us to maximally operate according to our values, priorities and core principles?" This is the question of alignment (a concept I will explore further in future posts). If the answer is "no" then are you willing to do something about it?

Tags: agile, process, scrum

One of the facets of the Agile methodology I appreciate is the emphasis on transparency.  Rather than ignoring the proverbial elephant-in-the-room, Agile helps us to quickly identify (and hopefully address!) the real issues that affect our teams.  This aids the continuous learning process as we must constantly face hard realities and find creative ways to address them.

A vital part of the Agile process is the retrospective.  In this process, the team members identify the events which have occurred during a previous time-period.  They then seek to discover patterns in these events.  Finally, the culmination comes as the team identifies ways they can continue doing what is working, improve on what is working, and avoid doing what has not been working.

It is important to enter the retrospective process with a dispassionate view as to the events which have occurred prior to the retrospective.  It is non-productive to place blame on individuals or circumstances.  Instead, we must work together to face reality in the form of hard facts. As we reflect on these factual events, we work collaboratively to identify possible solutions that enable the team to reach for ever more productive heights.

This isn't to say there is no room for feelings in a retrospective.  Certainly the team members may experience a range of emotions as they reflect on the events of the previous time-period.  But the idea is to avoid any form of us-them mentality, or to blame circumstances for the outcomes.

Retrospectives can be an exhilarating and enlightening experience.  They are a great tool for improving the continuous learning of your teams.

Tags:

Curiosity killed the cat - Eugene O'Neill

What is true for the cat is completely untrue for the agile team member.  The best agile teams place a high value on learning.  Curiosity is the catalyst for knowledge acquisition and creativity.  It helps us remain dispassionate about personal preferences and can unlock our potential for divergent thinking. Often it seems that curiosity is reserved for R&D or design processes, but the best way to maximize its potential is to stay curious throughout the entire product development lifecycle.

Curiosity when planning.  This is a vital element in a design process.  We need to stay curious about potential features and requirements.  We need to stay curious about resource allocation possibilities.  We need to stay curious about platforms, tools and technologies.

Curiosity about processes.  There is no perfect process, but there are processes that fit better for a particular context or situation. We should not simply assume that what worked before will work now.  We should not simply assume that what is new is better.  We should continually mold and shape our processes for maximum effectiveness.

Curiosity about personalities.  Our curiosity can be applied beyond the particular task at hand by extending it to the consideration of organizational culture, people, relationships, interactions and influence.  This can enable us to work better together and to maximize the potential of our teams.  This can also help us diffuse conflict by minimizing presumptuousness and assumption, and instead choosing to remain curious about why other team members are acting in a particular way.  

Curiosity when pondering.  Retrospection is reflecting on what worked, what didn't work and what could work better in the future.  Curiosity helps us to look deeply into our processes, our planning efforts, and our personalities to learn the lessons that will help us hone our skills and achieve better results as we move forward.

So if your goal is to effectively function as an agile team, reflect often, ask a lot of questions, and seek to learn from every possible facet of every possible situation.  Place a high value on staying curious.

Tags: agile, scrum