Agilification

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

Last week I wrote about my need for Dependency Injection for the Compact Framework.  Many DI frameworks do not support the Compact Framework, so I identified four options:

1. Don't use IoC and dependency injection
2. Continue to "roll-my-own" dependency injection tool
3. Pray that Jeremy Miller ports StructureMap to the Compact Framework
4. Use Ninject

Well, there is a fifth option that I hadn't considered: finding an open source project that does what I need.  Germán Schuager pointed me to a project he created on Google Code called Compact Container. It is lightweight, clean and simple.  After reviewing Germán's code, I found that it would support most of my needs, short of a couple of nice-to-have features.

1. Marking the injectable constructor with an attribute
2. Setting a default object life cycle for a container (rather than having to pass in the life cycle every time a type is registered with the container)
3. Ability to resolve concrete types that have not yet been registered with the container

In the spirit of open-source, I created the necessary code and sent it back to Germán for inclusion in the project.  As of this posting, he's included the constructor attribution feature in the source repository, and hopefully he'll also add the other features as well.

My struggle with Ninject came down to the fact that it operates in a fashion quite distinct from other DI frameworks. I must admit that the Ninject DSL is quite appealing, but certain things that I'm comfortable doing with StructureMap are difficult if not impossible to attain using Ninject without creating a bunch of direct dependencies on the Ninject assemblies.  So it looks like Compact Container is the winner at this point.  We'll see if it sticks.

 

Tags: agile, ioc, s.o.l.i.d., compact framework, dependency injection

I've spent the last 2 years developing WinForms and ASP.Net MVC applications, so it's been a while since I've worked on a .NET Compact Framework project.  In case you haven't heard of it, the .NET Compact Framework is a compact sub-set of the .NET framework that can run on devices with limited resources (like phones, blackberries, barcode scanners, etc.).  As I began working on the project, I decided up front that I would use the same SOLID principles I use on any other application.  I almost hit a roadblock, however, when it came to choosing a Dependency Injection framework.

I began with just a simple roll-your-own dependency resolver.  But this solution doesn't work well once you need to inject multiple layers of dependencies and build up your object hierarchies in a more complex fashion.  So I did some research into which (if any) DI frameworks support the Compact Framework.  It turns out that only one DI framework supports the Compact Framework: Ninject.  Typically StructureMap has been my DI container of choice, and recently I've spent some time evaluating the Unity container from Microsoft, but neither of these support the Compact Framework.  So I guess I've got a limited number of choices:

1. Don't use IoC and dependency injection
2. Continue to "roll-my-own" dependency injection tool
3. Pray that Jeremy Miller ports StructureMap to the Compact Framework
4. Use Ninject

Option 1 is not even a real option.  There are too many benefits to be gained from loose coupling and depending on abstractions rather than details.  Option 2 seemed feasible at first, until I needed more complicated object hierarchies.  I can't hold my breath and wait on something that may never happen, so Option 3 isn't a real option either.  So, it looks like I'm going to be heading to Ninja school!  I'll let you know how it goes and what I discover along the way.

Tags: agile, ioc, s.o.l.i.d., compact framework, dependency injection

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

How do you know if you are an agile software developer?  How do you know if your team is agile?  It is easy to say you are.  It is easy to intend to be.  It is easy to lose agility if not continually maintained.  On long projects focus shifts often.  Success is a moving target.  Agile practices have to be retuned and reapplied periodically.  That’s how it was intended to work.  That’s what makes it beautiful.  It’s a solution to be implemented later.  

The Agile Manifesto is a guideline for writing better software.  You could say it is a loosely coupled collection of best practices.  The Agile Manifesto does not contain a significant amount of detail and I believe that’s intentional.  It’s composed of a dozen flexible recommendations.  It’s not a script or a rigid doctrine of rules.  There is room for interpretation.  This freedom allows for easy adoption.   It also allows for radical variations.  Care should be taken not to let freedom become an evil mutation of agile practices.  If in doubt or debate, remember, “Working software is the primary measure of progress.”

It’s easy for teams to allow existing bad habits to remain when moving towards a more agile environment.  Understandably, old habits die hard.  Agile teams should actively identify their bad habits and discuss ways to eliminate them.  Allowing bad habits to evolve and masquerade as an agile practice is an evil mutation.  To avoid this, a team should continually improve their process.  Review the Twelve Principles of Agile Software as a team.  Eliminate rigid and strict processes.  Remove unnecessary steps in processes.  Find new ways to improve efficiency.  In short, tailor your process to best serve the team and your users.  Determining how best to implement the Agile Manifesto is up to you.

The Agile Manifesto has a lot to offer software developers.  Being agile in your profession is not limited to the software industry.  Many teams can learn lessons from the guidelines put forth.  Just as the software industry gained inspiration from a patterns book written on architecture.  The Agile Manifesto makes good sense in the work place.  So, if you strive to be agile, you should ask yourself often; self, are you agile?

Tags: agile

The title of this post is not a command to readers but more of a request to myself.  I believe strongly in starting any project, any feature, with a simple approach.  Correction, the simplest approach.  I write code to satisfy requirements.  I know my first attempt is not the final solution.  I promise myself, with every line I write, I will improve this code when I have more time.  The time stipulation is the kiss of death.  Improving your code should be a personal priority.  Time constraints can be overcome with discipline.

Help Yourself, Help Your Team
Start your sprints with code, start your sprints with tests.  You cannot refactor code that does not exist.  Write code! It will probably be bad; even the gurus write bad code.  This is why alphas and betas are so prevalent in the industry.  No one gets it right the first time and if they did--we wouldn’t need refactoring or TDD.  Developers need to combat writers block like a traditional novelist (keep coding).  Strive for improvement, ask your team to review your code. It’s okay.

Experienced programmers should encourage their inexperienced counterparts to code.  Let them drive when pair programming.  Resist the urge to interrupt the linear learning process.  Programmers tend to be hard on themselves and even harder on their peers.  This is an extremely anti-agile practice.  Agile programmers succeed together and fail together.  That is the precious gem that makes ‘Agile’ more than just a buzz word.

Tags: agile, refactor

Agilification is dedicated to agile software development principles and team management practices.  To find out more, check out the Agile Manifesto and the Principles behind it, or subscribe our our RSS feed to get updates when new content is added to our site.

Tags: agile