Feeds:
Posts
Comments

Archive for the ‘Management’ Category

Last week I revealed a little game/exercise that I have been running to demonstrate the difference between activities and behaviours in a non Agile environment versus an Agile environment and how the activities and behaviours shift to the team and the Scrum Master/Iteration Manager. I would like to now share the results of the game. I have run it twice, one with a strong group of Agilistas (Scrum Masters and Agile coaches) and a second time with a group of Project Managers. What surprised me is that despite the differences in the audience the result was pretty much the same. Maybe it was luck, but I am keen to hear of others running the exercise and if they get the same results (a few people have already shared with me that they have subsequently run it and got a similar outcome). The group of Project Managers that I did the activity with had a really good smattering of Agile practitioners in it which I believe helped to get a similar outcome. In this respect, I am concerned what the outcome would be like with a pure audience of Prince 2, never done Agile, Project Managers.

So what were the results for round 1?

When round 1 is conducted, almost all cards are voted to be best aligned with the role of the Project Manager. The following were the behaviours/activities there were not voted to be a Project Manager’s:

  • Deliver the work right
  • Deliver value
  • Quality focused
  • Is 100% allocated full time
  • Delivers the right work
  • Challenges the norm
  • Encourages learning culture
  • Mentors team

Which left the Project Manager with the following behaviours/activities:

  • Facilitates meetings
  • Primary stakeholder is Sponsor
  • Primary stakeholder is the team
  • Primary stakeholder is customer
  • Sustainable pace focussed
  • Coaches issues
  • Manages ability to deliver outcomes
  • Removes roadblocks
  • Trains approach
  • Resolves issues
  • Enables rather than controls
  • Makes decisions
  • Handles people issues
  • Directive, provides answers now
  • Has budgetary control
  • Ensures benefits realisation
  • Delivery focused
  • Supports approach

My thoughts on the round 1 results

The following were my thoughts on the results for round 1:

  • I thought it was interesting that it was the team and not the PM that was perceived to challenge the norm. Is this an admonition from PMs that they don’t push back on unrealistic timeframes or goals?
  • The PM’s primary stakeholder is considered the team, the customer and the sponsor… all at the same time. This question was deliberately worded to force a ‘x over y’ response and yet there was a strong drive for all three roles to be the primary focus for the PM. The conflict between these roles is inevitable and in my belief this is the key weakness of the non Agile environment model – one of these roles will win out over the other two and in my experience, it is unfortunately not the team nor the customer that wins.
  • I was somewhat surprised that PM’s felt that facilitating meetings was a core behaviour/activity. I normally would have thought this would have gone to the Business Analyst role but it could depend on how you interpret the question and what facilitation means.
  • I was very surprised on the sustainable pace response. I believe there is a gap here of what PMs believe to be true versus reality. When push comes to shove, most PMs I know would push the team to work extra hours/weekends to get a project over the line. I know that there are many of you who are good PMs that don’t do this, but the majority would.
  • Additionally I was very surprised that a PM would be coaching issues. Again this may come down to an interpretation of the term “coach” but I am using it in the purest sense that of ‘not providing answers, but instead asking questions to the team so that they themselves reflect to reach enlightenment on the issue’. I’m sorry, but I actually don’t think I have ever seen a PM do this.
  • Likewise I’ve never seen a PM train anyone.
  • Enables benefits realisation is a tricky one. I do believe that PM’s care for and look out for benefits realisation, certainly very much at the start of a project, but as the project progresses and trade offs begin to be made it is the better of the PMs out there that deliberately report and get validation to the trade off of benefits against time. That said, few PMs stick around long enough to see the actual benefits realised which I believe is sub-optimal as they are not receiving feedback on how well or not they hit the mark on delivery (to me delivery is more than just dates, cost and scope).

What were the results for round 2?

When round 2 was completed, the Scrum Master was given:

  • Facilitates meetings
  • Coaches issues
  • Enables rather than controls
  • Primary stakeholder is the team
  • Removes roadblocks
  • Mentors team

The team were given:

  • Delivery focused
  • Sustainable pace focused
  • Deliver the right work
  • Deliver the work right
  • Is 100% allocated full-time
  • Delivers value
  • Quality focused
  • Supports approach
  • Challenges the norm

Split very evenly between both the Scrum Master and the team were:

  • Manages ability to deliver outcomes
  • Resolves issues
  • Trains approach
  • Makes decisions
  • Encourages learning culture

The Product Owner was given:

  • Primary stakeholder is customer
  • Ensure benefits realisation
  • Directive, provides answers now

The following were put into the category of “Other”:

  • Handles people issues

And lastly, the Project Manager had:

  • Has budgetary control

The following was questionable as to where it belonged (if anywhere):

  • Primary stakeholder is Sponsor

My thoughts on the round 2 results

The following were my thoughts on the results for round 2:

  • What is most clear in this transition are two things, firstly the Project Manager is left with only one responsibility and the rest have been quite evenly spread between three roles – the Scrum Master, the team and to a lesser extent the Product Owner.
  • Secondly, there is the separation of primary stakeholders against role. The Scrum Master has the team, the team has the Customer and no one is left looking after the Sponsor. I don’t think this is necessarily correct and would imagine that the Product Owner has the Sponsor’s back, but this would likely also have a conflict against the Customer’s needs. What do you think – in an Agile world, who has the Sponsor (the supplier of money) as their primary stakeholder? In an Agile world should a “Sponsor” exist and if not where does the money come from?
  • I love that in an Agile world it becomes everyone’s responsibility to guide others (trains approach), encourage learning, resolve issues and make decisions. Some may argue ‘what if the team disagrees between themselves on an approach’? This doesn’t mean that it goes to a vote for the decision, it means that the team works through the pro’s and con’s and becomes more aware of the depth and breadth of the issue. A leader will always step up for the decision, but it is only done after a more collective understanding is reached.
  • Sustainable pace is probably the hardest issue to balance in an Agile environment. There will always be a push from the Product Owner and management to go faster and harder, especially if there is the ‘frozen middle’, a layer of management that does not understanding the essence of Agile. Dates are commonly still unrealistic for many teams and this leads to the inevitable push to work longer hours. Now with the Scrum Master accountable to the team they will likely be the first to push back against this, but the pressure can be immense. For my two cents I have sometimes given in on having a short burst of extra hours, never longer than a month. But let me be clear, I do not believe it helps the team in the long run, nor do I believe it is a good idea due to the impact it has on the quality of the product. This has been proven many times in studies and I have seen the results of even a month of bursting and what it does. Just don’t do it.
  • It is interesting that the Product Owner is seen to be directive and provide answers now, but if you think about it, to some extent that is what we are asking them to do. We want them to give us a quick resolution on a question so that we can meet our goals.
  • Handles people issues was shifted out as it was now likely being handled by a Team Leader.
  • And lastly, the budget problem. If a PM is only left with handling the budget then is it really a role? There is a huge shift towards “Feature teams” – teams that do not form and disintegrate on a project by project basis. In essence work is broken to fit into them rather than teams being formed to fit the work. This results in teams that only go through the Forming-Norming-Storming phase once at their initial creation or subtle dynamic change. The individuals in the team know each others strengths and weaknesses and most importantly they have a fixed team cost. If all work in the organisation is broken down to features that are implementable by the product feature teams then the problem of funding for software development really just boils down to one fundamental question – “What is the most highest value work that this product feature team can be working on?” Then it becomes a somewhat simplified matter of watching the cycle time for the product backlog and seeing the lead time for features to determine if more feature teams are required for that product, or less. In essence, it takes the problem from being a project issue to being a operational issue.

Final thoughts

theory_x_y

For those Project Managers out there that are believers in “Theory Y” there is unlikely to be much of a negative impact on you when you shift into an Agile environment. You are already a supporter of empowered teams and consequently this transition should feel very natural and in a lot of respects will result in a better work life balance for yourself as your old duties get spread more when you take on either the Scrum Master or Product Owner role.

But for those Project Managers who align more strongly with “Theory X” then there are some tough choices for you ahead in your future. You can choose to find work in an alternative organisation that isn’t about to go down the Agile path anytime soon. There are still plenty such organisations out there, but be aware that over the next ten years the number of these will likely shrink.  You may not be able to run forever. You can try to hide. You may be lucky and not have a good number of Agile Coaches in the organisation who will spot you and elevate your “Theory X” ways to management. PMOs are great hiding grounds, until they are wiped clean.

Or you can change. It won’t be easy, in fact, it will be months and months of hard work, but you may find an enjoyment and peace that you never experienced before when you make this leap of faith.

For the “Theory X” managers, let me leave you with this parting quote and good luck on your journey.

It is difficult to get a man to understand something when his salary depends upon his not understanding it. Upton Sinclair’s Dictum

Read Full Post »

At a recent Project Manager meetup group in Sydney, I wanted to spend some time covering the difference between the Scrum Master versus the Project Manager role. I figured what better way to do this than to have the group themselves collaborate in an Agile way to guide the answers?Scrum Master vs Project Manager

So I created the Behaviours And Responsiblities Game, or BARG for short.

Let’s go into how it works:

  1. Setup enough voting cards for everyone in the room. There are four voting cards for each person: Team, Other, Scrum Master and Project Manager
  2. Round 1 kicks off with only using the Team, Other and Project Manager voting cards. Headers match these cards on a wall. Preset cards are read out of behaviours and responsibilities that are commonly encountered in project teams and the voters are encouraged to nominate which role predominantly performs the role or exhibits the behaviour. Round 1′s key context is that of an environment that is not Agile. It could be waterfall, it could be RUP, it could be pure common sense.
  3. As each behaviour/responsibility is called out the card is placed against the role with the highest number of votes. If you have more than 40 minutes than feel free to use additional time to discuss variances where they are quite opposed. Cards can sit between two roles to show the varying opinion.
  4. Round 2 is kicked off with exactly the same set of behaviours and responsibilities. New headers are placed for all four roles which now includes the Scrum Master. It is also recommended to include a Product Owner role. Round 2′s key context is that of an environment that is Agile.
  5. Step 3 is repeated again.
  6. Take time now to compare the results between the non Agile environment and the Agile environment. Walk through any placements you disagree with but take care not to move any placements.

The cards that I included:

  • Facilitates meetings
  • Primary stakeholder is Sponsor
  • Sustainable pace focussed
  • Coaches issues
  • Manages ability to deliver outcomes
  • Primary stakeholder is the team
  • Removes roadblocks
  • Trains approach
  • Resolves issues
  • Enables rather than controls
  • Makes decisions
  • Handles people issues
  • Directive, provides answers now
  • Has budgetary control
  • Primary stakeholder is customer
  • Ensures benefits realisation
  • Delivery focussed
  • Is 100% allocated (full time role)
  • Deliver the right work
  • Challenges the norm
  • Quality focussed
  • Deliver the work right
  • Delivers value
  • Mentors team
  • Encourages learning culture
  • Supports approach

Bring along a few blank cards and feel free before starting round 2 to ask if any key behaviours or responsiblities for the Project Manager have been missed. I found that I had missed in retrospect two:

  • Plans timeline
  • Reports to steering committee

So what were the results? Stay tuned, I will post in a week or so. But in the meantime, predict what you think occurred – what shifted where? What didn’t have anyone accountable for it? What was no longer needed?

 

Read Full Post »

For those that have been on the Agile journey for a while this post will hopefully come as no surprise, but if you are fairly new on the journey I wanted to take the opportunity to clarify what I feel is a common misconception about Agile.

In the early days of Agile we made it a Waterfall versus Agile war. It was one or the other. One over the other. This when ‘x’, that when ‘y’. We spent time explaining the pitfalls of Waterfall and why Agile was better. Maybe that was right at the time. Maybe we did it because we didn’t know better. Whatever the reason the concept of an Agile transformation being replace old process with Agile has stuck around.

But I don’t think that the point of an Agile transformation is a process shift.

I have a suspicion that where Agile has succeeded, it did so not because of the process shift but because of something else – a thinking model shift.

What was the problem that we were trying to fix with Agile? Was it really the process or the mindsets that people had? The manifesto articulates it somewhat – “Individuals and interactions over processes and tools”. It isn’t that process isn’t important it is that the thinking model that process should always trump was broken and that some slack should be given to humans who may have felt that the process didn’t make sense given the complexity of the situation.

Somehow, despite the manifesto, when we began Agile transformations we ignored the “over processes and tools” somewhere along the line. Frameworks and certifications are springing up everywhere – SAFe, Kanban certification, Disciplined Agile Certification, ICAgile, Scrum, etc. How many of these are focused on process and technique over the ability to shift thinking models?

What I feel Agile should be is different now than it once was. What I feel the manifesto should be now, is more along the lines of:

We are uncovering better ways of working together as human beings to deliver value  to shareholders and delight to customers whilst at the same time improving the engagement of employees. Through this we have come to value:

  1. Synergistic thinking over mechanistic/analytic thinking
  2. Servant and situational leadership over command and control management (alt: unleashed human potential over apathetic or toxic environments)
  3. Full value stream optimization over sub process optimization
  4. Process experimentation over defined process
  5. Aggressive feedback controls over prolonged feedback controls
  6. Stimulated neurological pathways over stagnant neurological pathways (alt: learning culture over sole focus on delivery culture)
  7. Breathing space to enable creativity and innovation over 100%(+) utilization

That is to say whilst the things on the right are our current behaviours, we want to shift to the items on the left

 

Read Full Post »

shortcutRecently reading Dan Pink’s Drive, I was mesmerised by a statement of leadership type classifications. I wondered whilst reading it if there was a way to short cut the interview process to get the right type of leader by asking the following question:

We believe here at <Company X> that people fundamentally dislike work and would avoid it if they could. They don’t take responsibility for their actions and badly need direction. We want managers at <Company X> to co-erce, control and direct their staff to put adequate effort to the achievement of the organisations objectives – are you the sort of person that relates to this and can help us with this?

Now what you are actually seeking here is not a positive affirmation. What you are seeking is the look of shock and horror. The right person is the one that says “I’m sorry but this is definitely not the place for me; thank-you for your time,” and walks away. Most people wouldn’t do this, they would dance around the question, but a real leader is the type of person that will stick up for their beliefs and despite the negative impacts to them will stand firm. It takes juts to say no to this sort of question, especially this early in the process of understanding the organisations culture. It takes honesty to speak true to your beliefs. It takes a leader and not a manager to negatively respond to this question.

What do you think? Would this short-cut work if you were trying to hire an Agile leader?

Read Full Post »

purposeSometimes there are moment in life when like a bolt out of the sky you have a major self realisation. I had one of those moments recently when I realised that for a majority of my coaching life I have been pushed and prodded by my leaders/managers to behave as a Purpose Driven Agile Coach.

What is a Purpose Driven Agile Coach?

It is a coach that is asked/told that when they implement Agile that there needs to be a plan to improve capability. Targets are set and tracked weekly. An example could be, “Improve stand-ups within the month”, it is still very open ended but the practice it is linked to and the time frame is set.

I would imagine that this is quite common in organisations with low Agile maturity and very strong old school management mentality. In these cases, organisations want to predict and understand the value that Agile Coaching provides. Often this is linked to definable metrics, before and after of Agile capability in teams, but I often felt that this capability was shallow. I would be pulled and moved onto another team before I had a chance to really embed the change and ensure that behaviours didn’t regress. I was often only given the time to teach the ‘shu’ basics and never the time to allow for trancendence to ‘ha’ (and certainly not ‘ri’).

But lately I have been less pressure bound from a coaching perspective (I still have pressure, it is just different). This release of pressure to not plan has resulted in me using a different model – Opportunistic Agile Coaching.

What is an Opportunistic Agile Coach? 

It is a coach that only course corrects or teaches based upon the moment, taking into account both team and individuals mental model readiness, change value and change fatigue. Let’s break this statement down some more.

Mental model readiness is about whether the team or individual is in an intellectual state of readiness to receive the coaching advise/support/inception reflection idea. For example, I might personally believe that the benefits of estimation are limited, but the team may have given the concept little thought. Mental model readiness is about whether they have been asking the same questions themselves or whether I have introduced the inception reflection idea. I say ‘inception reflection idea’ because it really is like the movie Inception – you want to seed the idea or consideration in the team as to whether the practice is worthwhile or not and give them time to reflect on it.

Change fatigue should be fairly simple – how much change is the team or individual currently dealing with? If they are completely new to Agile or are mentally still coming to grips with some concepts of Agile then I am less inclined to make drastic changes. For example, if they are familiar with Scrum terms such as PBI and Sprints, where as I am more comfortable with saying Stories and Iterations, I will just go with their flow and not introduce name conflicts for the sake of it.

Change value is about whether the team or individual will get much (if any) improvements from the change. By improvements I mean faster client feedback, improved customer value, improved personal engagement, etc.

Regardless of which Agile Coaching method, I have always started by mentally creating my own backlog. It is easy for me to see what practices need to be improved and where. Sometimes if there are a lot of issues or the complexity is significant I will write it down as a real backlog and estimate it. To some extent, I have always done coaching with opportunistic elements – ie I gauge priority by change value and do take into account mental model readiness, but when there is no set plan, then it is really very liberating.

As a problem or situation crops up I can assess it against where the item fits in my mental backlog. If it was bubbling up closer to the top then I will use the opportunity there and then to address it. I might let certain opportunities pass as they are still very low on the list, but what might have been tackled four weeks later in a planned approach is addressed on the spot, with immediate context and relevance.

Relevance to revolution vs evolution in Agile models

My realisation of the existance of two Agile Coaching approaches, purpose vs opportunistic, made me then immediately think of the revolution versus evolutionary debate in the Agile community. A purpose based approach is more closely aligned with a revolutionary approach where mass transformation is expected/desired and cookie cutter conformance is achievable due to standardised but complicated teams. A opportunistic approach is more closely aligned with a evolutionary approach where incremental change is made based on team readiness and self-realisation – there is no cookie cutter conformance and there is a realisation that there is no such thing as standard teams, or that teams that are dealing with complex problems.

Conclusion

I know we would all like to think of ourselves as opportunistic coaches, but how many of you are really doing purpose based Agile Coaching and is there a right/wrong way?

Read Full Post »

It is highly regarded among many in the Agile community that:

  1. One of the most common causes of Agile transformational failure is due to either the lack of focus on or lack of effective change of the middle management layer.
  2. One of the more common successes of Agile transformations is when small, incremental or evolutionary change is encouraged (rather than what I have termed “legion” style transformation which includes massive roll-outs of training and sparse support).

But I wonder if there is a better way, a way that combines these two points together for more successful, albeit slower and less Agile Coaching consultative heavy model -

Rather than trying to teach Agile inside of an organisation day 1, instead work with the middle management layer to re-introduce learning as one of their key practices.

learning

If middle managers spent one to two days a week learning what do you think that would do to the organisation? I think it might kick start the organisation in all sorts of unbelievable ways. I think middle managers, rather than being forced to have these new approaches thrust upon them, would instead be the most passionate advocates for them. They might not choose to try Agile, they may want to try something else, but at least they are experimenting and thinking wider than just the day to day firefighting.

I know some managers already do this, but it is the exception and not the rule. But why is this? Do managers stop learning because they think it ends at university? Do they stop learning because they think it ends when they finally get into a leadership position? Or is it because they no longer have time anymore? Always in meetings or always fighting a fire?

Maybe the only way that managers will have the time to create a learning culture is if they limit their work in progress and begin to trust and empower their staff more? Now if managers start to trust and empower their staff more because they have to limit their work in order to learn, it is sounding like a win-win to me.

What do you think?

Read Full Post »

When I mentioned to some community friends that I was going to be reading Steve Denning’s Radical Management book a number of them looked at me as if I had contracted some form of virus. “Why would you read a dumbed down book on Scrum?” they said.

The answer for me was simple -

  1. Agile, I feel, isn’t an easy concept for Managers to get. I wanted to check the three prominent books on the market that are there to help Managers become Agile in order to see which one I would recommend if I ever had a manager (which admittedly to date I haven’t) one of them asked me for a recommendation.
  2. Because I do feel that it is hard for Managers to get Agile I wanted to see if there were any hints to what I could do differently or on what practices are relevant for Managers.
  3. I really like Steve Denning’s HBR articles. He has a beautiful writing style which I can appreciate for its simplicity and purpose.

Within this book review I won’t be comparing this book to the other two (although I might do then when I review those), instead I want to focus on my thoughts as I read the book.

Firstly, focusing on my third point above I was not disappointed. For the most part I did continue to enjoy Steve’s writing style in this book. Most pages I felt engaged in and whilst the pages didn’t all fly by, certainly up to the end of Chapter 9 they did (from there it does drag on a little).

Secondly, for a manager that has absolutely zero understanding of Agile and has focused for most of their management tenure on traditional command and control methods, either intentionally or not, I feel that this is an excellent book… to start them on the mental journey.

Which brings me into my third point. It tries to give a practical angle of applying it but I couldn’t in all honesty give this book to a Manager and expect them to be able to do the practices effectively. In fact, in a number of instances there is no detail on how to do a practice. So what this book does really well is get Managers to begin to question what they do and how they do it, less so actually enact change. This could be perceived as quite a concern for many but I don’t think it is that big of a deal – the difficulty is in the mindset change and this book does address well why you would want to shift from being a traditional manager to a radical manager. Additionally the book is riddled with references so if you did read this book and wanted to find more than there are a huge number of useful references at the back.

Now for the negative bits (which I don’t feel outweigh the positive):

  1. Some of the examples are poor – they don’t get the message across or they are weak links to the lesson. Steve is a good storyteller, just a few of the stories are duds. The first one in Chapter 10 is an example of a dud, as is the communicating example further in the same chapter. The roles in Chapter 1 also felt disconnected.
  2. The focus is strongly on Scrum. There is little content on Lean and only a sentence or two on Kanban. It would have been nice to have a broader view of being radical aside from Jeff Sutherland’s perspective. I was aware of this prior to reading the book so maybe I was a little more conscious of it than most readers would be. That said, I actually find that non Iterative Agile is an easier concept for Managers to understand.
  3. Iterations. I’m left with a feeling that Steve doesn’t understand what an Iteration is. It seemed to hint more towards an increment rather than an iteration. The examples that he gives on iterations are poor and for a fundamental principle I think it could have been articulated further.
  4. There are some occasional inaccuracies in advice (in my humble opinion) – like the concept that Value Stream Maps would find the phantom traffic jam problem and what defines “divergence” when using Planning Poker.

So it might be early days to know what book to give to a Manager to learn Agile (even if this was not the intent of this book and it’s intent was to be wider in focus), but overall I would give it a 7/10.

Read Full Post »

In April 2002 Rob Thomsett released his successful book Radical Project Management. Contained within was a little gem known as Project Success Sliders.

In normal Project Management there is a well known term called ‘the Iron Triangle’. This triangle represents the three key facets that a Project Manager needs to normally watch like a hawk – the scope, the cost and the time. In non-Agile Project Management these three elements are commonly fixed. In Agile Project Management these elements are defined at the start of the project, however as circumstances change we want a trade-off to occur. If we can’t meet our initial proposed scope, cost, time and quality then something has to give.

Generally I don’t allow team satisfaction to be traded off, it goes directly against sustainable pace and good leadership. Similarly I don’t normally have stakeholder satisfaction because ultimately that is a gauge of the four elements (scope, cost, time and quality) at play.

So what Project Success Sliders allows you to do is have an upfront frank discussion to acknowledge that it is hard to meet all four elements and that if something has to give what is it? Not all four can be possibly fixed. One will always be the most flexible, one will always be the most fixed. Two will be somewhere in the middle. This is about a conversation to understand critical needs.

So why do I raise the subject of Project Success Sliders?

In organisations I believe there is a similar model at play. I call them, for lack of anything incredibly imaginative, Organisational Success Sliders. Rather than the slider elements at play being time, cost, scope and quality we instead have Shareholder Value, Employee Engagement, Customer Delight, Supplier/Partner Symbiosis and lastly Environmental/Ethical Responsibility. The first three should be fairly obvious. The last two might require some explanations – supplier/partner symbiosis is about a mutually beneficial relationship. It isn’t healthy to screw your suppliers value down to nothing. It results in a loose/loose situation. Environment/Ethical Responsibility is about being corporately responsible with the world. How much is an organisation investing in being sustainable? In being carbon neutral? In ensuring that its suppliers aren’t using child labour in China?

Most organisations have Organisational Success Sliders set to Shareholder Value fixed at priority 1. Employee Engagement and Customer Delight are in the 2/3 slots, usually with customers winning over employee satisfaction. Supplier/Partner Symbiosis and Environmental/Ethical Responsibility are both vying for the last spot as the most flexible.

I want organisations to think of more than just Shareholder Value. I want them to consciously choose whether to put Shareholders above and beyond all other elements. Should these elements really be prioritized? Probably not, but they are, so call it for what it is and make is clear where the priorities lie. Only through firstly making this constraint transparent do we free ourselves to question it.

Read Full Post »

I have an hour to kill in the Vienna hotel I am staying at so I thought I would take the opportunity to do a brain dump of what I have seen and done Agile (or technologically related) as a bit of a midrospective:

  • Telstra are evil. I tried to get my phone working with an Austrian SIM card and the phone is hard coded to not allow any other SIM card to work in it. Several internet searches have found that this is due to the way Telstra and Apple setup the phones.
  • Apple is evil. For some reason unbeknown to me apple products don’t work on 95% of WiFi connections here (including my hotel, which was one of the reasons why I choose it). There is nothing worse than watching my hubby surf at ease on his android and me being devoid of any interwebs.
  • Austrian keyboards are weird. The z and y are around the other way. Count how many ‘Y’s there are in this blog. Each one of them I typed a ‘z’ in originally. Many of the special keys are in different spots or work using the right Shift or Alt.
  • I am finding some intriguing parallels between the history of Vienna and Agile. When I get back home I will write a more detailed blog but in essence there is definately a theme of people who were considered revolutionaries, who were incredibly passionate and entreprenurial but were ostricized for most of their lives. How they dealt with it and the ethics that they had I found very inspirational.
  • I have just finished reading Buyology whilst here. Again I will probably blog about it but again found huge parallels to Agile and Lean Startups. If you haven’t read this book then get a copy – it is eye opening and highly educational.

Non Agile related:

  • Surprisingly there is very little sunshine in Summer (it has rained every day)
  • Nothing opens until generally 10am. This would not be an issue if I didn’t wake up at 6am every morning. On the upside most things are open till late at night.
  • I’m sleeping really well. Walking about 7 hours every day will do that for you.
  • I need to buy another memory card. I have been taking about 400 photos per day (and processing them back to 100 at night). Vienna is truly an incredibly beautiful city. If you love jaw dropping architecture every time you walk around a corner then this is a must see destination for you.

Read Full Post »

For a while now I have been discombombulated. The cause of my confusion and desperation has been around the issue of management. 

I am not talking about Leadership. Leaders are people (whether in a position of hierarchy or not) that naturally foster an environment of collaboration, understanding and consensus. No, what I am talking about is the ability to influence creatively or constructively criticise the status quo to a person considered your “superior”. I want to use the term superior loosely knowing how much people will hate it, to represent an authority figure in a command and control environment. After all, Managers who aren’t getting the message about Leadership really do think they are superior (how many sweeping generalisations can I put in one post?).

I have come to the conclusion that a good number of employee frustrations are systemic from the culture; a culture which is powered by management. It is incredibly difficult to change culture from the bottom up. It can be influenced from the bottom up but there is a point where it cannot stretch anymore without management buy-in to the culture change. Failing senior management or C-suite buy-in to seriously throw money into changing a culture (yes culture change costs currency) I have been pondering how it may ever be possible for this problem to fixed in any way.

The C-suite don’t get it. Either they weren’t educated in it, don’t want to be educated in it or are too busy improving shareholder value. They are the Lords of this day and age, and how much did the Lords ever care about their serfs? Middle management are the Courtiers. Lower management are the cooks. Everyone else is working in the field.

Groups like STOOS believe that they can solve this problem through conferences targeted to the C-suite.  It is an interesting approach, but the sort of C-suite executives that will attend are the ones that I think for the most part are already on the journey or starting to question their belief system. It will make some in roads but I fear it won’t cross the chasm and I desperately ache for this chasm to be crossed. More needs to be done.

Others believe that they need to be right-shifted. I am admittedly still looking into this but have yet to get into significant enough depth to see if there is a mechanism to induce the chasm crossing.

I have been relaying this story a lot recently -

When a new person joins your team watch them closely. Watch how they learn and what they say. Watch how people react to what they say. Start to gather a pattern. What you will find is that when people join an organisation they are highly motivated. This is called the “Honeymoon phase”. The organisation is a veritible field of endless possibilities. They have been sold a dream by a HR department and manager.

The new person will listen for a while, enveloping themselves in the culture, trying to best see where they fit. They will start critically thinking early. They will ask questions like “Why do you do <insert task> that way?” They are trying to frame the task around their mind-map of how they have done it before and are judging it for efficiency and common sense. Failing a suitable answer they will delve further. Naturally they will gravitate towards the 5-whys, despite never hearing of Lean.

Eventually their critical thinking will be blocked by the “Monkey and the Banana syndrome” response. A root cause is not met and the first brick on the wall of critical thinking resistance is placed. As their first few weeks progress the same scenarios occur. Their brick wall begins to get higher.

When the wall reaches their knees self doubt sets in. Naturally they try to fight it, but in a different way. Rather than taking a critical thinking approach they will try a different tact. They will try the innovation path – providing suggestions of how they have seen it done elsewhere and the benefits that they had in doing it that way. They will get more Monkey and Banana syndrome responses or “We have tried that before, it didn’t work because <x> and <y>”, then the new person is back to the same lack of response to critical thinking. Innovation bricks now get added to the pile that is up to their knees.

After a few months their wall is up to their eyes and they can no longer see over the wall. There is no vision. No hope. The organisations culture is now embedded in them.

Sometimes I am asked what the Monkey and Banana syndrome is (usually younger people who haven’t heard it before). For those unfamiliar with it this is how it was told to me about fifteen years ago. I haven’t ever read the internet version so it may be a little different for those that have read it:

This is a story based upon a scientific experiment. A scientist puts into a large white room a metal ladder with a finger of bananas hanging from the ceiling. The middle step of the ladder is rigged to set an electric shock through the metal floor of the room. The scientist then lets in five monkeys. The monkeys excitedly see the bananas. One scrambles up the ladder and gets to the middle step. An electric shock is sent through the floor and ladder with all monkeys get shocked. The second time the monkey hits the middle step the other monkeys begin to get the picture. On the third attempt the monkeys pull the hopeful monkey on the ladder down and beat him up.

Subsequent attempts to climb the ladder result in beatings. The scientist then takes out one monkey and replaces them with a brand new monkey. This monkey sees the bananas and proceeds towards the ladder. He only gets two steps up before he is pulled down and beaten. He never knows why but after the second attempt he knows that if he tries to get up the ladder his peers will exert physical pressure.

The scientist continues to rotate the original set of monkeys out one by one and replace them with new monkeys. Eventually the room is filled of monkeys that have no understanding about why they are not allowed up the ladder but that if someone ever tries they should be beaten up.

“That’s just the way we have always done it around here.”

So you can see by my thought process that unlike some other thought leaders, I actually don’t think the ability to critically think is a lost art despite many years of behavioural conditioning supposedly beating this out of us. I believe critical thinking is a subconscious ability that we all have and continue to have despite command and control overriding it almost every single day. It is there. We have just given up trying to use it because no one is listening.

To get out of this endless rut I see a few possible solutions:

  1. Managers get better listening skills. Right now that you are done laughing, what are the other options.
  2. People get better persuasion and communication skills. On a scale of 1 to 10, 1 being highly unlikely to work and 10 being certain to work I probably rate this a 3.
  3. Have scientific metrics that prove empowerment, innovation and critical thinking are advantagous to the bottom line of an organisation. I am pretty sure the information is out there, but this depends on solution 1, and well, there goes that idea.
  4. Revolt. This is essentially option 2 but done on a less individualistic scale and more ganging up. This does happen naturally in teams but this method seeks pre-emptive goal setting. Despite being able to do this it will only work for one level above the team and from there will fizzle to get any traction, unless you get many teams to revolt at once and that is getting beyond the realm of possibility. Someone suggested to me that as an analogy it is like the monkeys ignoring the ladder and hopping on top of each other to form a monkey pyramid to get to the bananas.
  5. Teams get better facilitation skills and all team sessions have a pre-set, well skilled facilitator. In a team environment I give this a 5 to work, but outside of a team environment we are back to the original problem. That said you could encourage an environment where all suggestions of process change and innovation are raised through a facilitated team environment (sounds very Agile doesn’t it?)
  6. Enable a way to give a singular voice a pedastal. I am toying with an approach for this. I don’t think this will realistically happen inside of an organisation but I wonder if there is a means to force more social pressure for the C-suite to change their belief system.

What do you think? Are there other options to open up the eyes and ears of management?

Read Full Post »

Older Posts »

Follow

Get every new post delivered to your Inbox.

Join 920 other followers