Converting the strategy into activity

This week I attended an Ovum strategy briefing on Agile and agility. It was an engaging day with lots of good relevant experience articulated by some good speakers. I was particularly impressed with Colin Bird of Ripple-rock.

It didn't answer my perennial question about how much Agile is enough, but it did give some very clear pointers. Chief among them was the view postulated by the speaker from IBM that the pointers to agile teams are simply the regular delivery of usable software systems and cross functional team membership. He wasn't entirely prescriptive in stating which agile practices were essential but the nod was given to TDD.

As well as the technical software development techniques the other clear essential constituent was user stories. The representation of requirements as simple stories that can be understood or written by the business seems like a sensible way forward. These could be assessed for both effort to develop and given some form of business value. With a simpler method for capturing these wishes we could use them as the foundation for development planning.

Having been presented with some good strategic thinking the challenge is applying it to the organisation. Having a couple of significant changes to use as a starting point for agile implementation is a really useful tool. I intend to us it as a focus for generating some positive organisational change which is the way to move my personal effectiveness to the next level.

What to do next; tactical and strategic.

Having spent some time reflecting on what I want to set as the goal for the coming few years I have been struck by two trains of thought. One of which is about reflections that relate to my immediate circumstances and a desire to improve what I do right now and a second which needs a conscious decision about where I want to end up.

My first reflection was that I like what I do; the variety, the people, the challenge and the position. These factors all make it interesting and feel like a role that challenges and stretches me to just the right degree. There are some successes, but also there is an aweful lot to learn. But I am also aware of my own ambition and that I don't feel truly content unless I sense that I am working towards something more stretching. This has led me to conclude that the ambition is to continue in the same vane i.e. software development manager, but at a more senior level. Greater responsibility in terms of portfolio of projects and number of staff. More of the same, just greater challenges. This made me consider what it was I needed to do to acheive such an ambition and my thinking was that the first assessment should be what skills do I need to acheive a role at this elevated level. This is information I surmised that I could gather from reading job specifications that interested me and which fitted the bill, measuring myself against them and then planning to plug the gaps. All fairly straightforward then, but there is still a nagging entreprenereul streak that has never been truly sated. When I started freelancing I always assumed that one day I would build a substantial independent business. More recently I have taken a different tack, but I still think I need to spend time exorcising this unfulfilled ambition. After all, if the goal I aim for is not the one I truly believe desire then I suspect it is destined to fail. In conclusion the long term strategy needs some work, but what about the imediate tactical ambition?

This leads me to the second train of thought and how to be better in the here and now. I have probably articulated my sentiments on this previously, but I will reitterate them again so that hopefully even I take notice. I am generally pretty good, I care about what I do and so I get the job done. However there are times (lots of them) when it is harder than it needs to be and I am convinced that it is not about knowing what to do, it is about doing it. In a nutshell; consistent self discipline. So I have decided on a four point plan to try and stick to the activities that I know I should be doing consistently.

• Structured Task Management - recording actions from meetings prioritising tasks and getting them done.


• Time Management - organise the day by planning it before it starts.


• Consistent Reflection - spend time each week reflecting and post to the blog at least once a week.


• Strategic Analysis and Effort - spend at least one hour of the working week progressing my own professional strategic goals.

I believe if I can stick to these activities consistently then my performance will improve. To help me stick to these I am going to construct a weekly check list to monitor my adherence to the four point plan. The question is do I need a check list to ensure I am consistently completing the check list!

Time Out

I started this process (writing the blog) for a number of reasons. I wanted to spend some time each week reflecting on my performance and drawing out some lessons. My hope was that the act of writing the blog posts would encourage the discipline and regularity I needed. I also wanted the writing practice to help me improve my written communication including some level of increased creativity. The ultimate goal was to develop a system that would help me maintain an ongoing process of self improvement.

I would also say that I hoped it would build into my week the strategic career time that I had lost over the last couple of years. When I was a contractor working freelance I had a simple overriding principle; maximise income. There was never much consideration given to career, only employment. As a strategy it is a simple contextualising question; if I have options, which one leads to maximum income. I would target personal training to help me get the next role and so my career progression was simple. Now I am a manager in permanent employment I find that I am so busy I don't ever think where do I wan't to be in ten years. In the tactical sense I recently got another job. I hadn't been looking, but something came up and there was an offer. This made me realise that I liked my job and didn't want to leave. But it also made me reflect that I didn't really have a plan.

Now I am on holiday for two weeks and so I am intending to have a good think and get a plan. It frightens me the thought that I could drift along without any clear goals and so I intend to rectify that. But the really positive thing is that having tested out resigning I know that I like where I am.

Looking Three-sixty

I was listening to Peter Day's Global Business and he was interviewing Vineet Nayar who was explaining some of his management techniques. To reduce his thinking to a single line it would be stated as putting employees first. This runs counter to the paradigm of always prioritising customers. Clearly the model is based primarily from a service company background, but the principles probably extend further. Once again being slightly reductive the thinking is that value for an organisation is created by its employees. Hence the thinking that if they are kept happy then they are more likely to add value.

In many ways this is not revolutionary thinking as a happy workforce is a productive workforce. But what steps can a manager take to start to make this a reality. I would suggest that the possibilities are multiple but one good suggestion was very broad adoption of 360 degree feedback. In HCL all employees were encouraged to feed back on senior managers' performance. The benefits were twofold. Firstly the employees got the opportunity to provide feedback and the managers gained a valuable insight into their performance. Secondly the employees got to see that the senior managers were listening with a desire to improve the organisation and their own performance.

This all seems intuitive when you consider it and I have in the past sought feedback. But never would I have thought of such a wide audience for that feedback. So as we enter the appraisal process I intend to construct a simple online feedback survey. I can the circulate the survey and see what happens. Who knows, I might even learn something.

<br /><br /><img src="http://itshouldbeeasy.files.wordpress.com/2010/10/20101022-233524.jpg" alt="Agile Scrum software development manager" title="Agile Scrum" width="640" height="480" /><br /> Waterfall doesn't work or at least it is definitely good at failing. We deliver the majority of our projects using the Waterfall methodology, but there is usually a reduction of scope or a slippage on dates and certainly a huge dollop of risk. We constantly bemoan the fact that the requirements aren't clear and change as time goes on; but all attempts at remediation yield nothing. Enter Agile; the saviour of development teams the world over. This week I accompanied a number of previously cynical managers on an Agile Awareness course. Not so much a training course, as the instructor was keen to point out, more an outline of the overarching mentality, some of the principles and an attempt to highlight why it should be adopted. But what do you mean by Agile some might cry. After all, Agile is not one single process or methodology, more the heading for a whole raft of them. It was clear that the software development centric audience were keen to vociferously articulate the bug bear of incomplete and changing requirements. This is currently viewed as the biggest software development bogeyman. It leads to poor estimating, poor quality and inconsistent delivery; or at least that is what the squeaky clean software developers want to believe. Can Agile help? Clearly any system that simplifies the description of requirements and then iterates the development around them in tighter loops has to help. There is also merit in closer engagement between the business domain experts and the systems domain experts; all in a scrum I hear you shout. I think it is fair to say that the merits of Agile were there for all to see. By the end of the day it was clear to many that there could be some significant benefits to be had. It was also very clear that without significant commitment from the business we would not be able to secure any benefits. None of this is really news. Agile grew up because Waterfall consistently failed. But how much do you need to implement to make any development gain the Agile benefits. We don't have much Greenfield development and minimal use of technologies that support TDD. Very little take up of continuous build and or integration. So most of what we do in development is unlikely to be easily switched. My view is that the minimum we should aim for is breaking the requirements development issues. Why not create cross functional teams to get to to a clear specification of the delivery. Do the planning in the style of a sprint and get workable development task or user stories as a result. Still I remain unconvinced. I think I would conclude what I have always concluded. Yes some principles are worth adopting, but if you really want to go Agile then commit to a lot and not a little.

Waterfall doesn't work or at least it is definitely good at failing. We deliver the majority of our projects using the Waterfall methodology, but there is usually a reduction of scope or a slippage on dates and certainly a huge dollop of risk. We constantly bemoan the fact that the requirements aren't clear and change as time goes on; but all attempts at remediation yield nothing.

Enter Agile; the saviour of development teams the world over. This week I accompanied a number of previously cynical managers on an Agile Awareness course. Not so much a training course, as the instructor was keen to point out, more an outline of the overarching mentality, some of the principles and an attempt to highlight why it should be adopted. But what do you mean by Agile some might cry. After all, Agile is not one single process or methodology, more the heading for a whole raft of them. It was clear that the software development centric audience were keen to vociferously articulate the bug bear of incomplete and changing requirements. This is currently viewed as the biggest software development bogeyman. It leads to poor estimating, poor quality and inconsistent delivery; or at least that is what the squeaky clean software developers want to believe.

Can Agile help? Clearly any system that simplifies the description of requirements and then iterates the development around them in tighter loops has to help. There is also merit in closer engagement between the business domain experts and the systems domain experts; all in a scrum I hear you shout. I think it is fair to say that the merits of Agile were there for all to see. By the end of the day it was clear to many that there could be some significant benefits to be had. It was also very clear that without significant commitment from the business we would not be able to secure any benefits.

None of this is really news. Agile grew up because Waterfall consistently failed. But how much do you need to implement to make any development gain the Agile benefits. We don't have much Greenfield development and minimal use of technologies that support TDD. Very little take up of continuous build and or integration. So most of what we do in development is unlikely to be easily switched. My view is that the minimum we should aim for is breaking the requirements development issues. Why not create cross functional teams to get to to a clear specification of the delivery. Do the planning in the style of a sprint and get workable development task or user stories as a result. Still I remain unconvinced.

I think I would conclude what I have always concluded. Yes some principles are worth adopting, but if you really want to go Agile then commit to a lot and not a little.

If the door is shut stop pushing.

There has been a lot of debate in the last few days about the inclusion of a change into the current release. As a change it runsr alongside the constituent projects that make up the current quarterly release. It is independent in technical and management terms; but delivery requires some of the same resources in testers and environments. There is a view that it constitutes an extra logistical challenge but IT rebut this with the view that it is manageable and low risk. The business remain unconvinced.

It is clear that the assessment of risk is subjective and that the view is tempered with the level of desire to complete the change. In essence the zealous project manager is keen to get the delivery over the line in 2010 and so makes the case it being low risk as they know this gives them the greatest chance of success. The business on the other hand want to secure the bigger prize with as few issues as possible. This difference in perspectives is the key to the disconnect. As the business pays the bills they are the final arbiters and have stated clearly that the change should be deferred. Despite the unequivocal nature of the statement of priority the project manager continued to provide options until they were told to stop.

This has caused the project manager in question some considerable disappointment; but should it. On a personal level the delivery has slipped but only due to a business led priority call. The business have decided that the relative merits mean that the change can be held over. So it may just be that the business strategy that drives the decisions isn't always clear. I suspect that this is part of the problem coupled with a sense of personal disappointment.

As a result I intend to ensure that I have a clear understanding of the business strategy and then cascade the information out. I will also find time to see how we can ensure our approach to risk assessment is more objective so that we can be clearer when debating risks.

Criticism is feedback in disguise.

After a day out of the office this week I returned to my in-box to find a cryptic message from a team member at one of the remote offices. It was a request to get in touch which signed off with the ominous phrase "it's nothing serious". A phrase which immediately implies that it probably is something that one should be concerned about.

Without any real clue as to what I should expect I dialed the individuals mobile. In essence it was an employee in an office I had visited that week providing some interesting feedback. He wanted to inform me that the discussion at their daily meetings had touched on the fact that I was conspicuous by my absence from their regular scrums. It is fair to say that I don't directly manage the team or the project that is the current source of concern; but I do have a vested interest in the delivery of the project and the overall team performance.

I struggle to cover the miles to be in each office as much as I possibly should and part of the criticism was that when I am in the office I don't get close to the detail. I say the criticism as it felt that way. My instinctive reaction was "does he know how busy I am, I can't be baby sitting developers all the time". But I didn't express my thoughts and kept listening and accepted the feedback in good spirit as it was clear that it was intended that way. I thanked them for taking the time out to let me have the feedback and said that I would see what I could do to sort the situation out. I think that made a positive contribution to my image by not reacting negatively or defensively despite the internal reaction.

I discussed with the team leader in the location and I have built up a picture of the situation and consequently I will be back on site next week. But it has highlighted to me the need for honest feedback and the clear benefit of this kind of unbidden commentary as well as not reacting emotionally but listening and taking the criticism as honestly offered feedback.