septembre 2010Monthly :

in Agile, Management

A dead coach is a useless coach

Picture by WouterKvGDuring our monthly consulting services meeting, an interesting conversation took place. The conversation revolved around how to show traditional organizations the benefits of going Agile.

Granted, everyone around the table was already sold to Agile so everybody was working toward the same objective. The question was how to bring traditional organizations to switch their ways of doing things in order to adopt a more Agile approach? The debate was “Should we use a big-bang approach where all the energy is put toward getting the organization to take a quantum leap?” or “Is it preferable to use small steps in an effort to bring the organization toward the desired state?”.

Some people around the table argued that to quickly gain acceptance and shock the system, it is better to take somewhat of an extreme position and avoid deviating from the goal and as such, implement the Agile practices without consideration to the context.

Others (including myself) believed that the hard position and extreme approach doesn’t help much. It typically polarizes positions and creates an environment where conflicts are frequent. Personally, I believe that small steps taken in the right direction are much better than attempting to quantum leap forward when it comes to large scale transitions.

As consultants we are called in to help organizations transition from a current state to a future and hopefully better future. We bring our expertise and our convictions to the table in the hopes that we can influence these organizations. What happens when the consultants’ perspective collides with the organizational culture, values, processes and people? Of course, it depends.

Needless to say implementing change is a difficult task and if it was easy, nobody would need help (i.e. consultants). But when consultants adopt the following approach:

  • I need to change the organization;
  • The best way to accomplish this objective is to stick to my position – no matter what – until the organization realizes that I am right (i.e. they are wrong);
  • I will be successful for as long as I can hold my position.

What comes next is usually a dead coach…

Granted, the other extreme is no more useful when the organization thinks something like this:

  • What we have been doing is exactly what needs to be done;
  • We have all the answers and we will stick to our position – no matter what – until everybody accept the current situation;
  • We will be successful for as long as we can hold our position.

What comes next is an organization that will be less (and less) adapted to its environment and a Darwinian (survival of the fittest) consequence will happen.

So what is the right thing to do?

If you are a consultant, it is always a difficult balance between sticking to your position and completely letting go. The answer obviously varies by organization but sticking to a hard position is rarely (i.e. never) a good approach to actually change an organization.

Share

You might be interested in these related posts:

  1. Stuck in a dead-end job…
  2. What consultants don’t tell you before you begin an agile transition – Part 4: Why a coach is useful
  3. What the heck does an Agile Organizational Coach do?
in Agile

Agile Coaching : Baby Steps or Bad Precedence?

How do we go about to instill an Agile mindset and help teams deliver quality solutions?  The two main strategies are the “Big Bang” and pilot project approach.   I’ve never had the opportunity to go ahead with a Big Bang, so the alternative has been to find a cool project, get a team together, Scrum the hell out of it and watch all the nasty stuff come up.  With a few lessons learned and improved processes, start up a second team and so on and so forth.

During a transition process, I often use the same expression as when I’m writing a piece of code: Baby Steps.   Baby steps are a good thing! Write a small test, write a bit of code, make the test pass, refactor, rinse and repeat.  But in an Agile transition, baby steps are more like compromises.   That is, we start a Scrum pilot project and we “temporarily” set aside, bend or extend some of the principles of the Agile Manifesto and pillars of Scrum.

So when a team or an organization feels it necessary to not go full steam ahead with what I consider to be the best way to create quality software,  I constantly ask myself : Are we simply taking a baby step towards something more “agile” or are we setting  a bad precedence?

A few examples:

  • The core team is not 100% on the project- Baby steps or Bad precedence?
  • Co-locating teams might happen…one day – Baby steps or Bad precedence?
  • Little to no focus is put on improving Agile engineering skills – Baby steps or bad precedence?
  • The newly assigned ScrumMaster has never even heard of Agile, Scrum or XP – Baby steps or bad precedence?
  • The project is more mini-waterfall than Agile – Baby steps or bad precedence?
  • The first 25 items in the Product Backlog are non-functional requirements – Baby steps or bad precedence?
  • Transparency is set aside not to upset upper-management – Baby steps or bad precedence?

So if the members of team A are allowed to not be fully dedicated a one project, and a nonchalante “ScrumMaster” tech lead is assigned, what will happen when team B’s manager sees this?  Ya ya, I know… Team A and its manager will see the error of their ways, the appropriate changes will be applied quickly and team B will profit from those learning experiences all will be rosy in lala land.  Sometimes it happens but it becomes rare when it involves core practices of the organization.

So why do we accept this?

Well since excuses and justifications are the ointment to any compromise to the Agile Manifesto, let me offer you this one: If we, as Agile coaches push too hard, we are perceived as purist, not in tune to the reality and constraints of the organization.  Pushing too hard might actually result in the opposite of the desired effect and the Agile transition will force two worlds to collide and the whole thing will go kaboom!

Baby Steps or Bad Precedence?

So how do we make that call? Even better question, how do we bring a team and its organization to make that call and consider the short to long term consequences?  What is the break point between Agile values and half arsed Agile values?  Do we simply rely on common sense when common sense is often in short supply, or is there some kind of calculated “kaboom factor” that could help guide our decisions?

Baby steps are fine as long as we are not stepping right off a cliff!

in Développement logiciel

Automating your HTML validation using PyQuery.

I’ve recently started including view tests in my TDD/BDD pratice.

In my Django views(templates) tests, I needed a tool to help me test the presence of certain DOM elements. One of my favorite ways to locate DOM element in an HTML document is by using CSS selectors in jQuery.

I started looking around for a Python implementation of jQuery and found a great library called PyQuery that (thus far at least) has let me manipulate my views as DOM object just like I wanted to.

One way that I’ve used it thus it this far is to test that every single one of my template contains only valid HTML once rendered. When doing TDD/BDD with all my template I start out by writing a test that looks a bit like the following one :

class NewBlogTemplateTests(unittest.TestCase):

    def __getNewBlogTemplateRendered(self):
        return render_to_string( 'blog/newBlog.html',
                                { 'newBlogForm': NewBlogForm() }
                                )

    def itShouldContainOnlyValidHtml(self):
        theNewBlogTemplate = self.__getNewBlogTemplateRendered()
        assert_that(theNewBlogTemplate, is_(containingValidHTMLOnly()))

Behind the scenes, containingValidHTMLOnly is an Hamcrest matcher I have written using PyQuery and Multipart.

I will dig more into Hamcrest‘s expressive power in a future blog.

Here is the source code :

from hamcrest.core.base_matcher import BaseMatcher
from pyquery.pyquery import PyQuery
from helpers.tests import Multipart

class ContainsValidHTML(BaseMatcher):

    def __init__(self):
        pass

    def _matches(self, template):
        responseFromW3 = Multipart.post_multipart( 'validator.w3.org',
                                                  '/check',
                                                  {'fragment': template}
                                                  )
        pyQuery = PyQuery(responseFromW3)
        return pyQuery('#congrats') != []

    def describe_to(self, description):
        description.append_text('ContainsValidHTML')

containingValidHTMLOnly = ContainsValidHTML

W3c compliant HTML guaranteed by my automated test and my continuous integration build. I think this is pretty darn awesome ! Thanks PyQuery ! Special thanks to Jeff Balogh for teaching me in his blog this awesome use of PyQuery.

-Nicholas Lemay

in Management

I’m afraid that things won’t go well

Image by Capture Queen ™

The soft-minded man always fears change. He feels security in the status quo, and he has an almost morbid fear of the new. For him, the greatest pain is the pain of a new idea. – Martin Luther King Jr.

Do you ever face resistance when attempting to implement a new idea or a new concept? I often notice interesting behaviors when helping teams and individuals transition to Agile. In fact, I notice strange reactions whenever there is a change management initiative underway.

In such circumstances, the first question that comes to mind is “Why is this individual afraid?“.

In my opinion, people are typically afraid for 2 reasons: they have had a bad experience in a similar situation in the past or they anticipate that the change will cause unwanted results. Either way, my approach is the same.

Being afraid is normal and is not limited to humans (for sake of this post, let’s limit ourselves to humans). As babies we learn through experience and the recommendations of our parents – the stronger the initial experience is, the longer it remains encrusted in our brain.

Let’s admit that many change initiatives have led to very negative impact for people. Remember enterprise re-engineering? What about outsourcing? Do you think people who lost their job as a result might be afraid of other organization-wide initiatives??

As change agents, it is our role to dig into the reasons behind the fears. I’m not talking about psychology, I’m simply talking about root cause analysis of the situation in an attempt to properly address the concerns. To do so, coaches must ask powerful questions and keep silence to make room for valuable information to be shared.

Once we understand the motivation or the source of the fears, we then need to be truthful and honestly tell if the situation will (or won’t) lead to the feared consequences. In the cases where it may actually lead to the expected consequences, we should engage the individuals into finding potential solutions or way to mitigate the unwanted conclusions.

Share

You might be interested in these related posts:

  1. Agile transitions are hard. I wonder why people feel the need to control?
  2. Using silence as a communication tool
  3. How can someone Join a Community? Can people leave a Community?
in Agile

Agile Lessons Learned #12 : Making Room For Passion

The autonomous individual, striving to realize himself and prove his worth, has created all that is great in literature, art, music, science and technology. The autonomous individual, also, when he can neither realize himself nor justify his existence by his own efforts, is a breeding call of frustration -Eric Hoffer

In Agile literature, a lot of focus in placed on team members needing to organize themselves. But what about the managers role in providing a proper Agile environment ?

In every management class I’ve ever followed, one of the chief concerns was that managers need to be leaders. Leadership is often summed up as being able to motivate other people into performing better than they normally would without your intervention.

Things that push me towards greater accomplishments are when I can follow my passions and be passionate about what I’m doing. I also feel that my profession feels much more inspiring when it is viewed as being a craft that I need to perfect rather than being a series of tasks that need to be done.

Thus for me, part of a perfect manager’s role would be to put in place a working environment where individuals can live out their passions and perfect their craftsmanship while staying in line with the company’s objectives.

Are you lucky enough to be working in such en environment ? Here are a few questions that might help you figure it out :

In your current project, how much influence do you actually have in the outcome of the project ? Do you feel like a driver, a passenger or a bystander ?

Is becoming better at your job valued in your company’s culture or viewed as being overzealous ?

How much time have you been able to invest, at work, in becoming better at your craft ?

In the past 5 years you’ve spent at your job, did you truly acquire 5 years of experience or was it just the same year repeating itself 5 times ?

How many new things have you learned in the past year ? How do you think the next year will be ?

If you could produce a rather short list of your passions in life, how many can you follow while being at work ?

If you were to discover a new work related passion, what are the odds you could switch positions to follow your new passion ?

Last but not least, did your manager ever take the time to actually know what truly motivates you and your fellow colleagues ?

Luckily for me, I answered favorably to most of the questions. Did you ?

-Nicholas Lemay

in Développement logiciel

Keep Your Code Where It Belongs

The Story

I just bought a new computer. For the first time in ages I didn’t feel like spending hours deciding which parts I wanted, so I went for a big brand PC. Of course it came with Windows 7 installed.

Like any self-respecting geek, the first thing I did was… to install Starcraft. No problem there.

The second thing was to install Ubuntu. Then things started to get hairy. I could reboot to Windows once. Then the Master Boot Record. In case you don’t know, the MBR is a very important part of your disk that tells it what to boot. I was stuck.

Time for google. Fortunately I came across this page. It basically says “Some programs write to the MBR, overriding Grub 2′s boot code”. It then goes on to explain how booting from another drive (not an option for me), using LILO or reverting to Legacy Grub. The last one worked for me.

The Point of the Story

Anyway that got me thinking about a golden rule of software development : keep your code where it belongs! (Most likely, it does not belong to the boot sector.)

I can’t remember how many times I saw software fail because someone decided it seems to be a good idea to modify the internals of a framework/platform and commit it. Then the day comes when you want to use a new feature – and all hell breaks loose.

There is always a better option. If you think your project is different, think again. 99.9% of the time you’re wrong. If you think you’re in the .1% – so does everybody else. Otherwise you end up with an unbootable PC, a Tomcat that cannot render .jsp (yeah I saw that) or an application that is stuck with an obsolete, unmaintained version of a library that you can’t get rid of.

Keep your code out of the framework. You’ll stay sane a lot longer.

in Agile

Open Source StackOverflow alternatives

There seems to be at least 2 open source StackOverflow alternatives that are worth it :

  • Shapado : ruby, mongomapper, mongodb
  • OSQA : python, django, South

So, as usual, we see the python & ruby communities working on actual, useful applications, while the Java community is busy creating frameworks and libraries ;-)

Oh, no, sorry, the Java community is already busy debating on the future closure syntax,  if they ever decide to include them ;-) It looks like the java community needs a BDFL

in Développement logiciel, Ergonomie logicielle

The next big thing is Usability

Usability is something most teams outside the Apple circle do not care about.

However, luckily enough (or sadly enough, depending on how you see it), developers are keyword-addicts, and some things suddently start looking cool as soon as they are trendy. Nobody cared about the business logic before, but now that  Domain Driven Design is considered the new, cool thing, some developers start putting their effort into the domain, instead of the technical details.

Now, it looks like that two of the new, trendy architectural approaches will help us regarding usability, as they are focusing on user interactions :

  • CQRS : User Commands are an important aspect of the architecture, that defines the transaction boundaries of the system
  • Data Context Interaction : DCI is a vision to capture the end user cognitive model of roles and interactions between them.

Will these trends save our software ? ;-)

in Agile, Management

911 – “I need help! I’m a people manager and my team is going Agile…”

Image by Michael RansburgIn line with a few posts I recently published (this one and this one) and following conversations with people (and managers) around me, I decided to take another stab at helping people managers transform into agile leaders. Contrary to popular beliefs, people managers in an agile context are not doomed to buy pizza for their team and getting out of their way…

One of the underlying principles of Agile is to help organizations become more adaptive and flexible in order to (more) quickly react to changes in their environment. In this context, the agile manager has an important role, despite the fact that his traditional responsibilities can greatly change.

In his new role the agile manager needs to acquire or develop these abilities:

  • Adapt your leadership style: Every team reaches a certain level of maturity and the agile manager’s leadership style needs to be adapted to the context of his group.
  • Make yourself available: Your team members will need help and they will need to turn to someone they trust. Make yourself available and keep an open mind when problems arise so you can actually do something useful for them.
  • Help your team remain focused: Well jelled teams tend to become enthusiastic about what they can accomplish and sometime lose focus and get distracted by shinny objects – this is especially true with software development teams. In his role, the agile manager can greatly help his team members keep their focus in order to achieve their objectives.
  • Secure resources: In every traditional organization, departments are typically assigned a budget to provide a certain level of service and as such, the self-organized team rarely has the maturity and visibility to obtain the budget it needs to protect and grow the unit. The manager remains the best spoke person for his team since he has developed the political abilities to influence people around him.
  • Become a consultant to the team: Develop your credibility as an expert in certain areas and make sure to bring that value to your team members. As a rule of thumb, you shouldn’t show up at their meetings unless you are invited.
  • Guard the team from disruption: Once the self-organized team demonstrates a high level of performance, others around will notice and are likely to request activities, tasks or special projects from the highly performing team. The manager must then block disruptions and maintain the team’s focus in order to remain productive.
  • Be a spoke-person and do marketing: The team will want to achieve a high level of performance and once it does, recognition from others is a likely contributor to their motivation. The manager is an position to promote the success of his team – and indirectly his own as the manager of a highly performing team. If you believe “marketing” to be inappropriate, think again. After all, the manager delegated some of his authority to the team and as such deserves to get recognition.
  • Increase communication and visibility: A lot happens outside the team. The manager has to bring the information about the organizational threats and opportunities back to his team. Sometime even gossips can be useful information for the team.
  • Prepare the team for the future: As the team undertakes some of the traditional management responsibilities, the manager can spend some time actually preparing the team members for the career development, especially if some of the members are interested in developing their management expertise.
  • Offer to help with retrospection: The team is typically very focused on their activities in order to achieve the objectives that were defined for them. As a consequence their retrospection are likely to focus on short term, immediate challenges they are facing and much less about the long term. The manager may offer to facilitate meetings geared toward the future.
  • Grow the team members: Observe the team in action. In collaboration with the individual team members, determine which area they wish to develop in order to achieve their career goals and support them by coaching them.

Overall, in such a context the agile manager needs to start focusing on a strategic perspective as opposed to a very tactical one which is often what managers do despite their many promotions over the years.

The change is likely to be positive not only for the team but also for the manager himself – only if he develops enough self-confidence and courage to start operating this way.

Share

You might be interested in these related posts:

  1. I don’t feel so good – I’m a people manager in an Agile organization
  2. The 7 Dimensions of an Agile Project Team
  3. Are you an Agile Leader? – Nine questions for people managers