Saturday, 2 March 2013

<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.



Agile Scrum software development manager


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.

Saturday, 8 December 2012

Criticism is feedback in disguise.

Software Development Manager Criticism is a valuable source of feedback

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.

Don't forget number one; career developmemt is important for all.

Remember your own personal development;don't miss the train. Software Development Manager. IT Should Be Easy

Succession planning has been a common theme in recent times and has given me the chance to seriously consider developing the team. Indeed this year has given ample opportunity to coach and improve those that work for me. But what about my personal development. I started 2010 with a clear view that it would be a challenging year; a sharp increase in the scale of responsibility including a broad geographical split and new born twins. All in all a lot to contend with.

But I am starting to get on top of things now. The last nine months have given me the chance to grow into the role and whilst it will be a long way before I am proficient, I am getting there. So now I need to consider what next. In order to keep growing and to improve the management capability further I need not only the short term goals that have underpinned the year so far, I now need a more strategic set of aspirations.

So this weeks short post is a placemarker to say that the weekly reflections are great; but it is now time for a deeper dive. Lets start to try and map out the next three years rather than the next three months.

Saturday, 1 December 2012

Leading From the Front.

Yesterday I was fortunate enough to be invited to the firms inaugural Leadership Conference. A well organised affair where all mangers within the company were brought together for series of presentations on Leadership. Each session was presented by senior leaders within the organisation and they were all intended to encourage the man managers within the organisation to consider certain themes in their day to day leadership activities.

I have been on a number of leadership and management courses and there was nothing especially revolutionary in the underlying messages. For me the resonant theme was all about aspiring to personal levels of over achievement that would serve as an example to ones subordinates. It is a very simple principle but exceedingly powerful. The key concept was that a team member is unlikely to try and outperform if he doesn't see the same desire to over achieve in his boss.

Another statement which really worked for me came from the MD of one of the business units. He outlined a number of qualities that he associated with strong leadership and chief amongst them a quoted 'a positive attitude'. This made me consider a previous reflection about demonstrating confidence to those around you to build their confidence. I think this reflection on positivity falls into the same category.

Keen as I am to extract tangible actions or achievable behavioural changes from a learning experience I am moved to consider my demeanour. I think the key is to develop an internal level of positivity that can shine out. The superficial 'have a nice day' smile will not suffice this is all about an outward reflection of inner strength and positivity that truly leads as an example to others. To make this happen I have resurrected the personal mission statement and I intend to read it at least once a day. Time to lead from the front with a smile on my face.

The Three Cs of Software Development; Communication, communication and communication!

The projects I tend to come into contact with very often span development teams. In particular two very specific teams located in the same building one floor apart. These teams are both led by technically capable young managers who have been promoted from within the teams. One of these managers reports to me and one does not. Given the proximity, the similarity and the situation you would think these teams would work well together but very often they do not.
I am not sure whether there is genuine tension, but given the need for them to work in harmony and the plentiful examples of them not; I can only conclude that there is an issue. Having spent some time considering the reasons and circumstances that have surrounded some of the conflicts it soon became clear that the difficulties were never present face to face. From this I have concluded that the difficulties revolve around the communication between the two. The more I reflect on the power of communication the more it occurs to me that it is the first weapon deployed in the manager's armoury when an issue surfaces. Very often the cry goes up 'let's get everyone on a call'. So opinions are expressed, circumstances exchanged, options considered and above all, I believe, empathy enhanced. Very often conflicts arise when we don't understand another person's perspective and whilst talking about things doesn't guarantee that alternative view point is understood, it rarely does any harm.
This leads me to conclude that communication is essential. Whether the news is positive or negative if we take the opportunity to express our views and understanding we open up the door to empathic connection. So from now in I will take every chance to engage in meaningful communication whilst facilitating and encouraging it in others.

Saturday, 24 November 2012

Optimism is great; but is not the basis for a sound project plan.

I hold my hands up; I occupy both ends of the optimism vs. pessimism spectrum. I am an optipess.

Embroiled as I have become in the latest fire-fight that calls itself a project I can see the fundamental failure of our forward planning model. If I was looking for a metaphor to describe the forward planning model it would be like a man buying a new pair of jeans. You can see the sizes and you know you used to be a 34" waist and so you are sure they will fit. To test the hypothesis you shoe-horn yourself in and stay standing still fully exhaled; a perfect fit! The moment of truth comes two hours in to the first period of wear when the discomfort becomes all too apparent.

So it is proving with the current project. We made all manner of assumptions in the early planning that supported what we wanted to deliver. It also supported what the business wanted us to deliver. For a short period of time it all looked very rosy. Until the assumptions started to unravel. Firstly preceding tasks overrun, then holiday knocked a hole in capacity, then people on the critical path got derailed and so it went on.

It may be that you are starting to think 'well that is basic project management'; I would agree, but with the following observations. The strength of a project is based largely on the quality of the estimates and the ability of the PM. In this instance we didn't have a dedicated PM until recently, but the more salient learning point for me is that there was never the voice of negativity. The assumptions and the estimates were too optimistic and there was no dissenting voice. This was good news for everybody, until the wheels come off and now we are faced with far more uncomfortable conversations.

So from now on I intend to plan with pessimism and deliver with optimism. Let's see if that works.