REA Group has experienced impressive growth since it was founded in 1995. A startup that began in a suburban garage, it now employs more than 900 people worldwide and is a top 100 Australian Stock Exchange (ASX) company valued at $6.78 billion. As REA Group continues to grow, the enterprise has embraced Agile and Lean […]
To me, nothing is more frustrating than context switching (i.e. multi-tasking). It takes away from our ability to focus.
You may have gone through this exercise (or one like it) in an Agile Bootcamp or Scrum Course; it’s called ‘Multi-tasking is worse than a lie’. Here’s how it goes…
Get a piece of paper and write the sentence: Multitasking is worse than a lie
Every letter you write, you should immediately write a number just below it, starting with 1 and going through to the number 27 as you reach the last letter in the sentence. So you write “M” and then 1, you write “u” and the below it 2 and so forth. You keep this up until last letter of the sentence and you time yourself.
Now try writing the sentence in full followed by the numbers 1 to 27 in full. Again, time yourself.
What I’ve found over and over again is that, on average, it takes just a little more than half the time in the second instance. We’re still doing the same amount of work, mind you.
Now think about how simple this exercise was. And about how complex the development of software is. And compound that by the number of projects and tasks you may be shuffling.
So the point is made, and everybody agrees that we need more focus and less context switching. And then we go back to our real jobs and get pulled in 10 different directions at once. It’s madness!
So why aren’t many of us willing to do something about it?
I spoke in one of my previous blog posts, ‘The Agile Coach on Courage’ about how standing up and telling your boss that you’re overwhelmed is hard, but necessary. It takes guts. Sometimes you’re being asked to be a member of several project teams at once. Other times, you’re being yanked off an active project (with little to no notice) to work on a pet project for a C-level executive. Telling your boss the consequences of such actions is hard to do, but necessary. And if they’re a good boss, they’ll actively listen to you, empathize, and try to remove any impediments that stand in the way of you getting work done productively and of the highest quality. True servant leadership.
But in order for them to help, you must let them know that this is disrupting not only your productivity, but the rhythm of the team as well.
Scrum Masters, listen up because this is on you as well. One of your major functions is to protect the team. So educate the Departmental Managers on the evils of context switching and multi-tasking. Press the issue tactfully. And if you don’t have enough people to get the work done, raise it as an impediment. Make it visible. Let it drive a discussion around the scope of the Product Backlog, the Release Backlog, or dates. Our velocity is what it is. You want to increase it? Adding more team members oftentimes won’t do it. In fact, it can even decrease velocity in the short term. So be careful of this tactic if you’re running up against a tight deadline. Let it be known that our team works at a sustainable pace. Yes, we can work longer hours from time to time when it’s really needed, but don’t let it become the norm and burn folks out. One of the telltale signs of this occuring is a spike in the number of bugs introduced, a simple metric to keep visible and discuss in your team retrospectives.
I’d like to hear your thoughts on this topic. How do you deal with context switching/multi-tasking?
Managers all over the world are faced with a critical challenge to their role. They ideas about management and their management style is being challenged. And this is even more important because many managers have reached a position of in their career where they thought they could "take it easy". Nothing could be further from the truth.
Today the role of managers in all industries is shifting. And in no industry more than the knowledge industry.In this video I explore why this is happening and where we may be able to look for solutions. I also present a concrete set of consequences that will affect you as a manager from the trends we are witnessing in the knowledge industry. Do you want to know more?
Sign-up here to read a white paper I wrote about the sources of disruption for managers and management in general. In it I explore where the key threats to the current management roles are coming from.Ready to explore what you as a manager can learn from The Science of Chaos?You came to the right place! :) Mystes in Finland organizes a workshop about Chaos Science applied to the challenges of managing small and large knowledge work organizations. You can visit their site to know more about the workshop and to sign up. Places are limited. In that workshop I will touch on the following topics:
- Current theoretical base for managing projects
- What is wrong with managing software projects today and why?
- What can we learn from Chaos Theory and how to apply it in real life projects?
- A model for a successful project using what we have learned from Chaos Theory
The ScrumMaster Tales is a series of stories about ScrumMaster John who attended one of my courses. He is the ScrumMaster for the WorldsSmallestOnlineBookstore.
Scrum succeeds because it helps build a high performance team, i.e. a team that is capable of delivering significantly more work than the individuals are capable of separately. The role of the ScrumMaster is to help build the high performing team through observing their relationships, helping them understand Scrum, improving their technical practices, improving their relationship with their product owner, and improving the organization they’re part of. Read this story through the lens of building team(s) and ask what John could have done.
After the stress of the last release, John and his team are slowly paying down the technical debt (mess) they created. They maintain a technical debt backlog, knocking off a few items every sprint in addition to the work they do creating new features. If they keep this up it will take only another three to four months before they’re as productive as they were before the release.
Jeff (CTO – Jeff -> Don -> John) calls John and Don, into his office. He says, “I have great news. The VCs have given us the go ahead to hire two new teams right now. Unfortunately they don’t think there is enough need to justify the hiring of any more ScrumMasters”. He continues, “John, I’m sure you can play this role for all of our teams. There can’t be anything more than scheduling a few meetings. John, we’re counting on you to make this a success.”
John has learned to speak up more than he had in the past, and he tries to explain that the role is far more involved than just booking a few meetings. Jeff, however, stands his ground. “I’ve just attended SAFe training and my trainer told me we could get away with a 1:4 ScrumMaster to Team ratio.” He continues, “John, I know you can make this work for us.”
In the following weeks, two additional teams are hired and John does his best to split his time fairly between them. He mostly abandons his own team (we will call them Alpha) and splits his time between the other two new teams. John, being an aficionado of personal improvement, keeps track of roughly how much truly productive time he has for each team just by measuring the number of Pomodoro he completes. Perhaps unsurprisingly, this number goes down. He used to average six a day, and now he only achieves four. (John has just discovered Multitasking – which is a great way to get everything done later at both the team and individual level.) Luckily, he’s figured out that he can mostly ignore his existing team since they’re already so far along the team performance curve.
Three months in, and let’s see how the teams are doing. The two new teams, Beta and Gamma, are struggling. Team Beta run all the mechanical elements of Scrum correctly, and they have all the meetings (Sprint Planning, Review, Retrospective and Daily Scrum). They have – and consistently meet – their definition of done, but it is so weak and watered down as to be useless. So the letter of the Scrum law is being practiced, with no spirit. There is limited collaboration and everyone is working in silos. Worst of all, the Beta Product Owner writes all the user stories for team members, treating them as order takers and not partners.
Our fearless ScrumMaster John has a fair idea about what needs to be done, but little time to act. Complicating things further, team Beta have decided that they’re really not a big fan of John since he never removes any of their impediments directly, instead challenging them to solve their own problems.
Team Gamma are off to a better start. They’re trying to follow not just the letter of Scrum law, but also appreciate that there is a spirit of collaboration. They’re really struggling to make it happen. They’ve heard all about Test Driven Development, Acceptance Test Driven Development, Continuous Integration, Collective Code Ownership, Refactoring, Simple Design, etc, however they’re having trouble getting past rudimentary Unit Testing. It took them several weeks to get a Continuous Integration server up and running as they were snowed under with requests from the Product Owner.
They need someone to hold their hands and act as a backbone when required. They need someone who can coach their collaborative skills, in addition to the technical ones. This team has a fair chance of becoming high performing, but are unlikely to do so by stumbling towards their goal. Their issues are two fold: they don’t really understand what’s going wrong, and John doesn’t have the time to coach them correctly.
Meanwhile John’s regular team is suffering under his almost complete absence. In an attempt to get the other teams up and running, John is only booking meetings for Alpha, he helicopters in to facilitate meetings, and then disappears again. As a result, Retrospective meetings are happening but the action items aren’t being completed.
The team had been focusing on improving their technical practices, but this has fallen by the wayside. They’ve been using Sonar to track historical information around their builds including: Build Failures, # of Unit Tests run, Code Coverage, PMD warnings, and more. In the past few months it’s easy enough to see that their technical quality has slipped. It would appear that, without John to question, they struggle to finish their commitment every sprint, even when it’s clear that they overcommitted. Worst of all, they seem to have forgotten about the importance of regular backlog refinement, because the product backlog has hardly changed in the past six weeks. This makes it increasingly likely that the team isn’t actually working to meet the current needs of the customers. Since they spent limited time collaborating on acceptance criteria, they’ve had more surprises where Product Owner Sue says that feature doesn’t work the way she wanted and it needs to be fixed.Analysis
What happened? John can’t possibly win here. His boss, Jeff, thinks that the role is part time. But he can illustrate that the role requires a lot more than part time, and help people around him see the costs of their choices:
- Use Sonar history from Team Alpha to show the general decline in technical quality (Be careful to make it clear that these are just general indicators.)
- Demonstrate that Alpha is achieving fewer backlog items per sprint than they did in the past. (You can measure velocity to do this but I would just count stories.)
- Demonstrate that the code being produced by the Beta and Gamma teams is harder to follow and making it more difficult to add new features.
- Show that all the teams are struggling to deliver features at all, and when they do, the features aren’t what the customer wanted.
- Show that Alpha team hasn’t made any real changes in the past few sprints.
In all cases, John can focus on the outcomes that business cares about: Happy Customers, Useful Features Delivered, Quality and Ongoing Improvement. Don’t focus on Scrum words, as the management couldn’t care less about those.
When you’re responsible for many teams, you don’t have time. So you will need to:
- Facilitate well – instead of taking the time to facilitate, John fell back to his prior command and control habits (alienating team Beta).
- Coach the Product Owner – a Scrum Team that doesn’t have a close relationship with their Product Owner will do a brilliant job of building the wrong thing.
- Coach the Technical Practices of the Team – once the mechanics of Scrum are in place, much of the productivity improvement comes from team members learning Test Driven Development, Acceptance Test Driven Development, Continuous Integration, Collective Code Ownership, Refactoring, Simple Design, et al.
- Coach the Scrum Process – John only has time to run meetings at this stage, not facilitate retrospectives, and certainly not to work with individual team members. (Normally I expect ScrumMasters to facilitate meetings, in this case John is so rushed he doesn’t have time to facilitate, and instead he just tells people what to do in the meetings. Running meetings will quickly impinge on the team’s ability to self organize.)
- Witness the Team in Action – part of coaching effectively is just observing – seeing what is happening both as individuals and between team members. Without witnessing the activities and actions, it’s harder to facilitate an effective retrospective that gets to the heart of matters.
- Definition of Done – the team needs to be consistently reminded what they’ve already agreed with respect to ‘Done’. They need to be consistently challenged to ensure that they honour their definition.
- Retrospective Action Items – it’s easy to commit to take action in the retrospective, but harder to follow through. The ScrumMaster provides the reminder of the importance of following through.
- Team Impediments Backlog – the ScrumMaster is responsible for maintaining the team’s impediments backlog, for keeping it up to date, and for highlighting problems that team members themselves can take.
- Technical Mess (or Debt) Backlog – effective teams maintain a list of their worst pain points in the code and are always paying them. Their goal is to extend the useful life of their codebase and lower the cost of change.
- Discipline and Focus – helps the team stay focused on the highest priority work and helps provide them with the discipline and backbone to make it work.
- Change the Organization – many of the problems that the team faces are at the organizational level, and any fixes we make at the team level are sub-optimizations. A good ScrumMaster is always thinking about the big picture as well as their own team.
This is far from an exhaustive list – just a start.
When you’re faced with the tough situation like this, what is the best way you could handle it? Some options in rough priority order:
- Full time, Dedicated ScrumMaster – gold standard.
- If one team is already doing well, have one full time ScrumMaster split over two teams. We have one person learning to play the role of the ScrumMaster more effectively and we already have one team working well. In this case our ScrumMaster can focus much of their time on growing the capacity of the new team.
- Full time ScrumMaster split over two teams – similar to number #2 – one person focused on playing the role well might be a better option than part timers. In this case the organization needs to acknowledge that it is delaying (possibly forever) both teams’ achieving high performance.
- Team member playing part time ScrumMaster at least 50% of their time focused on their team. Guarantees some time for the role to be played adequately well. Problem: the team won’t perceive you as neutral in dealing with conflict; personal task work often takes priority over the team. Solution: wear a hat when playing the ScrumMaster to remind yourself to stay neutral; work for the team trumps individual task work. In this case the organization needs to acknowledge that it is delaying the team’s achieving high performance.
- ScrumMaster for three or more teams – doesn’t work, refuse the role and ask for one of the above options.
If you need more help in showing someone the full time nature of the ScrumMaster role, try:
- ScrumMaster Checklist from Michael James: http://scrummasterchecklist.org/
- Cases for Dedicated ScrumMaster – Melinda Stelzer Jacobson: http://www.infoq.com/articles/case-dedicated-scrum-master
- Seven Things I wish I had known starting out as ScrumMaster: http://www.scrumalliance.org/community/articles/2012/may/seven-things-i-wish-i-d-known-when-i-started-out-a
Scrum is difficult enough to do in the first place. Don’t stack the deck against yourself by accepting more than you can possible handle.
I’ve been a supporter and user of NHibernate for nearly 10 years. While not part of the original NHibernate Mafia, I’ve long enjoyed NHibernate’s ability to rich, behavioral domain models. I wasn’t happy with the initial designs of Entity Framework, but since it’s been many years since that vote of no confidence thing, I wanted to revisit EF6, especially after the 6.1 release and rich code-first model. For the 99% case, it looked very similar to how I used NHibernate.
NHibernate is still a more mature product, and includes features that it’s had for literally a decade that EF doesn’t have, but for a couple of reasons I wanted to give EF a go on a real project and real domain model that was already using NHibernate successfully. Surprisingly, it only took me a few days to completely make the transition and have all tests pass. So why am I looking to make the switch? Two big reasons:
- With a couple big committers leaving the project, there’s a void in the leadership and direction of the project
- Bugs that I’ve run into have been open for years with no fix in sight
A project as large as NHibernate needs a strong OSS community to back it up, or barring that, corporate sponsorship. EF is OSS and has corporate sponsorship.
As side note, OSS as it currently stands in .NET is only currently successful if the project is small and targeted in scope, or has a company backing it, as seen by reading the tea leaves.
A lot of my opinions on Entity Framework were based on the 5 and 4 releases, so it was time to revisit a lot of my assumptions.Migrating
In my solution, I was already using the code-based mapping in NHibernate, making the switch in my configuration was relatively straightforward. Additionally, most of my configuration that was originally building up a Configuration class simply moved to my derived DbContext EF class.
Migrating my class mappings and usage was mainly an exercise in regular expressions. One of the reasons why I’m never too worried about switching out infrastructure components who have large feature parity is you find that the differences are mainly API differences, and those are easy to switch out. I don’t like abstracting my ORM, that’s largely a waste of time, and yet it still only took me in a code base of around 60-70 entities about a day to get a compiling solution. I did replacements of:
- ISession –> DbContext
- session.QueryOver<T> –> dbContext.Set<T>
- session.Query<T> –> dbContext.Set<T>
- Query<T>.Fetch() –> Set<T>.Include()
- session.CreateSQLQuery –> dbContext.Database.SqlQuery
- ClassMapping<T> –> EntityTypeConfiguration<T>
If you can write decent regular expressions including substitutions, you can perform 90% of the migration just by simple “Find and Replace” across the entire solution. And after 3 days, the entire solution was migrated from NHibernate to EF6.
I did have some problems I ran into. First, one-to-one associations are possible in EF6, but typically require…strange hoops to go through. Things like adding a FK to both tables, or creating combination keys. In NH, a two-way one-to-one association are possible with only one FK. Other things I ran into that don’t exist:
- Unique constraints (also the limiting factor in one-to-one mapping)
- Sophisticated second-level caches
- Read-only entities
- Global filters
Some of these are possible to work around, some aren’t. Global filters, for example, is very difficult to implement unless you have hooks in the infrastructure. With NHibernate, it was brain-dead simple to implement multi-tenancy with a tenant discriminator column. The good news is that these are all on the EF team’s radar and I didn’t need that specific feature in this codebase.
So why did I ultimately want to make the switch? It came down to a pattern of usage I’ve taken with regards to LINQ and AutoMapper. With NHibernate, anything beyond a very simple projection in LINQ wouldn’t work, but does work in EF. Given a choice of never having to worry about lazy loading problems ever, ever again without resorting to document databases and its baby-with-the-bathwater approach, I’ll go with EF.
Post Footer automatically generated by Add Post Footer Plugin for wordpress.
As an Agile Coach, I typically find two shifts in perspective helpful for new agile architects: first, the possibility of delivering slices of functionality (typically prioritized by risk or value) and second, the possibility of delivering slices of architecture required to support incremental delivery.
I experienced this perspective change personally in what now feels like a previous life as an architect who was expected to construct solutions in addition to architecting them. As a result, I thought it might be most appropriate to discuss how an agile coach might approach the second shift in the spirit of the art of the possible while at the same time trying to keep it simple.
My goal is to incrementally and iteratively formulate a framework to help coach a new agile architect through the required transition of thought in designing architectures that enable incremental delivery of value. While it does not require BUFD, it does require thoughtful consideration of architectural requirements such as quality attributes, NFRs, and expected points of volatility and extensibility. As will eventually become evident, the details contain gotchas that are easily avoided with due consideration.Two Potential Perspectives
The way my mind works, there are two obvious representations of the context.
In the first, I view an architecture using the following entities:
- Things – which commonly talk to other things using…
- Messages – which contain or, in some way, transmit…
- Information – for context, configuration or other processing
A second, and maybe more useful, perspective is to view the architecture in more traditional layers:
- Domain – the public face, internal or external, of architectural value delivery, typically in the form of services
- Capability – the functional or component building blocks
- Interaction – the integration of the capabilities that reside both in and on the architecture
While both perspectives resonate with me, for this discussion I will use the latter. In future posts I will delve in more depth, which will more naturally align with the former.What are the challenges?
So what are the challenges I commonly face in this particular area as an agile coach? The following are common questions that arise:
- How to support domain service stability during incremental refinement?
- How to incrementally increase the complexity of integration points while maintaining robustness and managing volatility?
- How to support component stability while incrementally increasing capabilities?
In addition, each case typically comes with requirements to ensure extensibility and backward-compatibility, as well as the realization of quality attributes such as scalability and performance.Recognize & Address Each Type of Challenge
As a result, any systematic approach that a new agile architect will find useful must address at least each of these types of challenges.
So I’d like to propose one way to look at this challenge and help your customers complete this mental transition. A particular benefit of this approach is that all the referenced content already exists, is in use, and has extensive information available in both books and the public domain. See the References and Further Reading section at the end.
So let’s dig into each challenge with a bit more detail.How to support domain service stability?
I suggest approaching this challenge with a discussion of Service Oriented Architecture patterns. The primary benefit of these patterns is to manage the dynamic and volatile service contexts and contracts encountered as the architecture is extended in increments. More detailed information for each of these can be found at soapatterns.org (see references at the end).
Some useful patterns to leverage in this way include:
- Service Façade supports dynamic service contracts by decoupling the core domain capability from the public contract. This will allow either the core domain capability or the public contract to evolve independently.
- Agnostic Capability helps derive new service contexts by making available well-defined yet common domain capabilities as granular services.
- Protocol Bridging supports protocol volatility by ensuring differences in communication protocols – either type of variant – are handled adequately based on expected protocol volatility, planned or emergent.
- Compatible Change / Concurrent Contracts generally support ongoing modifications by introducing new capabilities without impacting existing ones, and by creating multiple contracts of the same domain capability for specific consumer types.
For integration that will be changing through incremental architecture development, introduce the Enterprise Integration Patterns body of work (Hohpe). The primary benefit of these patterns is to stabilize points of integration from Day 1 as they increase in capability and complexity.
Some common refinement patterns to identify and plan for include the following, which I have personally experienced on several large-scale projects:
- Basic Integration Refinement occurs as a simple integration becomes more complex and capable. An example evolution of integration may include transitions from hard-coding, to file sharing to shared memory to RPC, and finally to messaging. Using other protective patterns, this refinement can evolve with minimal impact to the solution and customers.
- Message Channel Refinement involves the paths of integration becoming more powerful and robust. For example, message channels may transform from Point-to-Point to Message Bus to the use of Message Bridging. This would use the EIPs called Point-to-Point Channel, Message Bus, and Messaging Bridge. (Hohpe).
- Message Routing Refinement occurs as the routing mechanisms used to put messages on channels move from relatively dumb to elegant and smart. Some examples I have used to incrementally build out a robust routing infrastructure include content-based routing, message filtering, Recipients List, Splitter & Aggregator, Composed Message Processor and Message Broker. While the core integration may have also required change, it was minimal compared to the message routing capabilities protected by architectural design patterns.
This is probably where most technicians are the most familiar, yet it is worth discussing within your coaching conversation as this not only ties the other pieces together but also provides more tools which can be applied at all levels. Here we consider GoF Patterns at the capability level.
Some common design patterns that bring great value to incremental delivery include the following from Design Patterns:
- Factory Method to abstract and extend creation functions. Through a creation interface and inheritance, the implementation determines which class to instantiate. In addition, more simple factory patterns that do not rely on inheritance may also be applicable here.
- Adapter, Bridge, Decorator, Façade, and Proxy to protect and stabilize structure. Each of these leverages abstraction to stabilize areas where the structure is or may end up being volatile. In most cases, if the extent of true volatility is less than expected, the cost expended for protection will have been minimal.
- Strategy, Command, Mediator, and Template Method for incremental extension of behaviors. Again, through the power of abstraction, component capabilities and behaviors can be extended as needed with minimal impact to the core solution.
My goal is to create a systematic approach to engage and coach new agile architects in the art of the possible when it comes to architectural slicing. Using generally available and proven patterns at each critical layer of an architecture: the domain, the capability, and the integration, architectures can be designed, communicated, and built in vertical slices which meet quality attributes and stability using an incremental delivery approach. As a coach, communicating this possibility and providing the tools to new agile architects is critical to empower early and often creation and delivery of value.What do you think?
- What other patterns have you found useful for slicing architecture?
- How have you communicated this technical challenge to new agile architects?
- Would such a system be of use to agile coaches in the technical realm?
The posts that will follow this will go into greater detail to describe my coaching perspectives on the:
- benefits of specific patterns to slicing,
- gotchas to consider,
- concrete examples from enterprise projects and
- steps for using these tools which form their own pattern of analysis
…. all in the hopes to spark some thoughtful discourse and provide coaches with additional tools in the technical realm.
- “Design Patterns.” Wikipedia. Wikimedia Foundation, 14 Apr. 2014. Web. Apr. 2014. http://en.wikipedia.org/wiki/Design_Patterns
- Hohpe, Gregor. “Patterns and Best Practices for Enterprise Integration.” Home. N.p., n.d. Web. Apr. 2014. http://www.eaipatterns.com/
- “SOAPatterns.org.” SOAPatterns.org. www.arcitura.com, n.d. Web. Apr. 2014. http://www.soapatterns.org
- For additional reading on agile architecture check out a previous post by Mike Cottemeyer > Scrum Gathering Agile Architecture Talk
The post Coaching the Agile Architect – Creating Value, Ensuring Quality, and Empowering Change appeared first on LeadingAgile.
Before we try to answer them, let's take a look at whether scientific research is similar enough to software development for the values and principles of the Agile Manifesto to really apply!
Science is Different, but SimilarIn a commercial environment, there is usually someone who understands what needs to be done. In Science, figuring out how things really work -- and excluding other ways that things might work but don't -- is the the core business. What they have in common is complex problem solving. The feedback comes from users in case of software development and nature in the case of science (though much science involves software development).
Often scientific problem solving is so complex that only a very small number of people understand the underlying models and phenomena. This makes it difficult to simply delegate programming assignments. OTOH the scientists themselves are usually not good software developers. Sponsors of research come with a question they want answered, not a list of features to implement. Trying to select the optimal form of collaboration between scientists, software developers and other stakeholders raises a lot of questions.
The first special characteristic I noticed about the scientific environment was a strong "yes-but" culture. Unlike many commercial environments I have seen, the yes-but culture was not perceived as being toxic, though it did seem to cause some of the expected difficulties in cooperation -- or should I say, lack thereof? Still, challenging assumptions is essential to science. If you observe B, and want to show that A causes B, you have to exclude every other possible cause of B, before you can really conclude that A is the cause. Yes-but is a professional skill.
At the same time, developing an idea often requires a constructive yes-and mentality. Yes-but tends to kill ideas and to make collaboration difficult. So both approaches, yes-but and yes-but, have their place in Science. I am wondering if scientists were to be yes-but and yes-and into their hypothetical Manifesto for Agile Scientific Research, which one would be on the left?
Is the Manifesto for Agile Software Development Relevant to Science?"We are uncovering better ways of developing software, by doing it and by helping others to do it...." Scientists are not developing software, nor do they do research for customers (per se), so how much of the Manifesto is really relevant?
Suppose we make a few small changes to that manifesto? I used the following modified version to lead some thought exercises during the Scrum Training:
Draft: Manifesto for Agile Scientific Research
We are uncovering better ways of performing Scientific Research by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Scientific discoveries over comprehensive documentation
- Collaboration over contract negotiation
- Responding to change over following a plan
(with apologies to Alistair Cockburn and company!)This is the approach that the devops movement has taken, modifying the Manifesto to identify more directly with the challenges of running systems. But will it work for Science?
Step one is to try it on for size. Look for some practices that feel right or feel wrong. (I will skip the positive examples. Most companies that try this exercise find that the decisions that value stuff on the left are generally better both for their customers and for themselves than those decisions that value stuff on the right.)
Publish, Perish or Discover?"Publish or perish" is a well known fact of life in academic circles, and it is even more true in the Scientific community. To succeed as a scientist, you need to get published as the lead author (with a bunch of minions supporting you!) in an important journal. But what if your research is too big for one person? What if you're part of team? How can you reconcile working in a team when your career requires you to shine as an individual?
This proved to be a hot topic in the scientific community! Some scientists even questioned whether scientific discoveries and the published paper aren't the same thing!
Publish or perish is something of a fact of life, but it is in conflict with the needs of complex research -- think CERN with its billion-dollar, multi-decade research mandate. How many lead researchers can there be? What is the interest of a researcher to be a team player in a complex field, if the industry does reward such efforts?
This draft manifesto suggests that better ways of doing research will value discoveries over individual glory and that changes to the current rules of the game will be good for future discoveries!Towards a Culture of Continuous ImprovementI led my class through an exercise of identifying cases where the institute already values things on the left. These precedence cases confirm the validity of an Agile approach. Then they identified potential areas of improvement the would come by valuing stuff on the left more.
Then they prioritized these potential improvements to identify what would help the organization most. This produced a backlog for starting a continuous improvement in the research process. The most exciting part was watching the light go in in people's eyes when they saw how this process, if implemented consequently, could turn any organization into an awesome place!Agile Scientific Research?Being Agile doesn't mean simply doing Scrum (although Scrum may well prove useful in many scientific contexts). The juxtaposition of things that we value, e.g. discoveries and publishing, provides the basis for some fascinating discussions, which are resonating with the deeply important issues of the wider community.
The Manifesto for Agile Software Development is powerful tool for understanding the priorities in an organization or industry, determining whether you are really setting the right priorities, and for identifying improvements to make the organization (or even the industry) more effective. It naturally leads an organization to a culture of servant leadership. With a little bit of modification, it can serve many different human endeavors, including scientific research.
I hope that the principals involved here will remain intrigued by what they learned in their Scrum course and start to build a community beyond their institutional boundaries to look for better ways of performing scientific research, by doing it themselves, and by helping others to do it.
Nein, so meine klare Antwort. Vielmehr brauchen wir es händeringend, um voranzukommen. Natürlich bedarf es einiger Rahmenbedingungen, damit Feedback auch das bewirken kann, wozu es imstande ist – nicht nur auf der “Nehmerseite”.
Ein wirklich guter Topmanager neigt dazu, in seinen Meetings viel zu schnell zu sprechen und seinen Redefluß ca. 15 mal pro Minute mit einem „ähm“ zu unterbrechen. Ich habe es mehrmals gezählt und gestoppt. Dadurch besteht die Gefahr, dass die Zuhörer wichtige Informationen im Laufe eines längeren Vortrages verpassen, weil sie akustisch irgendwann nicht mehr folgen können. Ich selbst habe mich des öfteren dabei erwischt, dass meine Gedanken bei seinen Vorträgen abschweifen.
Was tut man nun mit so einer Erkenntnis, die durchaus unangenehm sein kann, wenn sie falsch rübergebracht wird. Klar ist, dass insbesondere der Feedbackgeber aus seiner Komfortzone heraus muss, um seinem Gegenüber einen Gefallen zu tun. Mit dieser Sicht fällt es schon mal etwas leichter. Wenn wir Feedback also als Zeichen absoluter Wertschätzung betrachten, so hilft es uns auch, selbst das unangenehmste Feedback zu überbringen (Körpergeruch, Hosenstall offen…). Wertschätzung deshalb, weil es unserem Gegenüber hilft, sich zu verbessern. Würde ich ihn nicht wertschätzen, würde ich das Feedback für mich behalten. Darüber hinaus gehe ich davon aus, dass das Thema Feedback immer magerer ausfällt, je höher ein Mitarbeiter gestellt ist. Aber auch der Topmanager ist ein Mensch und hat konstruktives Feedback verdient, erst recht dann, wenn er einen Berater dafür bezahlt.
Im genannten Fallbeispiel habe ich mein Feedback genau so eingeleitet: Dass ich Feedback als Zeichen meiner Wertschätzung empfinde. Und es wurde mir mit den Worten gedankt: “Danke, das ist mir noch nie aufgefallen und es hat mir noch keiner gesagt.” Ich sehe das als Bestätigung, dass sich bisher nur keiner getraut hat.
Wenn wir zusammengefasst das Thema Feedback als Wertschätzung betrachten und folgende Rahmenbedingungen beachten, so wird es leichter fallen und auf dankbare Ohren stoßen:
- Feedback geben, wenn es gewünscht wird.
- Feedback als Ich-Botschaft formulieren: „Ich nehme wahr, dass …“
- Nicht verallgemeinern: „Alle finden, dass …“
- Den Nutzen darstellen, der entsteht, wenn das Feedback angenommen und umgesetzt wird.
Abschließend möchte ich euch raten, mal selbst zu hinterfragen:
- Möchte ich Feedback? Warum gebe ich keines?
- Wem habt ihr schon durch euer Feedback geholfen? Was war da anders?
Dies sollte euch helfen, offener, konstruktiver und positiv mit Feedback umzugehen.
- Feedback geben können oder warum auch ein alter Hut gut aussehen kann
- Scrum Essentials: Die sieben Fragen der User Story
- Eine Erleuchtung: Scrum als Coaching-Tool!
I’m extremely proud to announce the latest release of the Unity DI container. We have updated it to simplify cross-platform development of apps and services. While this 3.5 release is filled with too many improvements to talk about, I’d like to highlight these two:
- Truly portable class library: We have transformed the individual platform targeted Unity into a PCL, including support for Windows Store Apps 8.0 and 8.1, Windows Phone Silverlight 8.0 and 8.1, .NET 4.5 and up, and new with this release is support for Xamarin/Mono (Xamarin.iOS v7 and Xamarin.Android v4.12). Xamarin support is significant as it makes Unity a truly portable class library, making it simple for C# developers to share code across devices.
- Performance improvements: We have streamlined the internals of Unity without impacting the public-facing API. In running micro-benchmarks, we have consistently seen a performance improvement of Unity core operations by ~60%. We encourage you to do your own perf testing and additionally validate our findings with your data.
The official release notes are available from here.
Grab the binaries from NuGet.
Enjoy this release of Unity and remember to send us your pull requests if you have ideas on how to improve it.
At Play4Agile, Olaf Lewitz and I hosted an exploratory session on personal growth hacks. Everyone shared ideas and turned into the self-appreciation game.Purpose of the Game
The purpose of the game is to give people practice at accepting praise and recognition so that we feel good about our accomplishments and successes. This cultivates our sense of self-worth so that we are more resourceful at work and in our personal lives.Why Play the Game
In our society there’s rarely room to learn how to accept praise and recognition. We squirm and say “it was nothing” because it feels uncomfortable. We have a hard time seeing our own self-worth and feel this disconnect when we receive praise.
This is a great game to help people and teams become more resourceful so they are able to co-create a more positive environment.
It is very helpful if you are working to create a people-oriented organization.Game Rules Setup
Form a circle. If you have more than 10 people, consider the option of forming two smaller groups.
Explain the purpose of the game and it’s mechanics.
- Brag Protocol: Pick something that you are proud of and share it with the group.
- Applause: Everyone cheers and claps to celebrate your success.
- Soak it in: Let the appreciation soak in like maple syrup in a pancake. Connect deeply and fully with the feeling for 10 to 15 seconds. See Hardwiring Happiness for further explanation of letting in the good.
Go around the circle 2 to 4 times depending on how much time and energy you have.Game Results
As we went around the circle the connection and trust increased. Everyone left this game feeling awesome.Why This Game is Important to Me
I am on an epic quest for self-worth so that I can engage with the world from a centered and whole place. So that I carry my own weather around inside me. The game was invented to help me level up on my quest. And it worked. I hope you are interested in similar benefits.Acknowledgements
We are deeply grateful to the participants of the workshop who helped co-create and test drive this game.
- Emotional Antidote Map: Identify and Mitigate Negative Emotions In my last post, The Business Case for an Authentic...
- The Business Case for an Authentic Workplace People are messy: they have personalities and emotions. In this...
- How to Hard-Wire Happiness to Develop your Leadership Capacity Would it be useful to learn how to hard-wire you...
Related posts brought to you by Yet Another Related Posts Plugin.
From our previous posts on April 16 and April 11, you know that our content delivery network (CDN), Akamai, was affected by Heartbleed and has been working to resolve the vulnerability. We have received confirmation from Akamai that they have patched the OpenSSL vulnerability and reissued all LeanKit certificates, thereby mitigating the Heartbleed vulnerability for […]
Each and every week, potential customers call us asking for our assistance in moving their team/division/product line/company towards a more agile environment. As we dig deeper into their challenges and what they want the end results to be, sure enough, one question always pops up – “So, how long will this take?” Now that’s a loaded question!!
There are several factors that can affect transition towards a more agile culture. Things like size of the organization, distributed or co-located teams, current ways of working, the end goal and business outcomes, executive sponsorship, etc., etc., etc. There is one other item that hasn’t been mentioned, and that many forget. It’s what I like to call “Cultural Debt”.
In this space we clearly define and tend to understand “technical debt” as a by-product of writing code the fast and dirty way, only to have to have this incur debt interest payments later that may impede our ability to develop new things. Cultural Debt, for me is similar. Companies build into their culture ways of working to simply “get things done” that many times can have lasting negative effect.
Companies become entrenched in the way they work now, and have an inability to think of other ways to do what they have always done. The longer a company works in this way, the harder the change effort may be. Companies with a high cultural debt may experience some of these symptoms:
- meeting overload, with no clear outcomes or purpose
- overfull calendars, with multiple projects in-flight at the same time
- fear of failure is prevalent
- most work is done when assignments are delivered, and workers wait for what’s next
- legacy processes that no one seems to own
- the organization structure is full of layers and layers
- email is the preferred method of communication
- many spend large amounts of time creating reports, not value
- there tends to be a “culture of blame” and CYA
- lack of joy for the product you build, the customer who uses it, and the people you work with
And many, many more…
Agile doesn’t “fix” all these things, but it does help make them visible. The key is to push through these difficult items, and pay down this “debt” in the process. For some this is a short process, and for others it’s very, very long…but the journey is worth it.
So, how long do you think it will take for your team? How about for your company? Tell us!
Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.
The post Decrease Cultural Debt, Be More Agile. But How Long Does That Take? appeared first on BigVisible Solutions.
At various times, the behavior of Facebook reveals to me that it’s a loosely coupled system with long latencies in synchronizing its various data stores. Just today, the iOS app asked me to confirm a friend request. When I did so, it gave me a pretty generic error—something about not being able to do this action at this time. That’s when I realized that I’d already accepted that particular friend request, days ago. That tells me that there are often inconsistencies between the database used with one interaction, and the one used with another interaction on another interface.
It also tells me that there are likely teams working on components, rather than features. If it was a feature team, the need for an error message would have driven a different underlying implementation. A feature team would want to differentiate between not being able to accomplish an action because it was already done, and because some problem was blocking it. For the former, there’s no need to show an error at all.
Instead, I can imagine they’re using some sort of “friend accept” API written by another team. That code either performs the acceptance, or reports an error. From an implementation point of view, not being able to perform the acceptance because it’s already done seems very similar to not being able to do it because the request has gone away, or the database can’t be contacted, or any other reason. This is a common problem when looking at things from an implementation oriented point of view.
When one team is developing the whole implementation stack for a feature, they’re more likely change the interface to suit the needs of the user of the interface. This may be aligned with the interactions of a person, or it may be aligned with the needs of another component. In either case, the capabilities of a component should be provided in ways that make the most sense for consumers, not the provider. If this is not done well, the team developing the consumer code will likely reach for the Adapter Pattern or Mediator Pattern in order to make it look, as far as possible, as if the implementer team provided a consumer-oriented API. Such an adapter can isolate the consumer from idiosyncrasies of the provider and provide a cleaner, easier to use API, but it can’t make up for lack of information.
It may be that I’m reading too much into this, and the situation is different than I imagine. There are many ways to screw up the design of software such that the deficiencies are noticeable from the user interface. The observed facts are consistent with the problems I’ve seen internally to code that I’m not at liberty to reveal.
- Pay attention to the user experience, particularly in the face of error conditions.
- Evolve component APIs, as needed, to support the needs of client code.
- Try to develop full-stack features, rather than dividing up the work in component teams. Use a hybrid if you need component expertise.
- If you can’t do that, collaborate across teams to enhance existing APIs to better support the consumer’s needs.
- As a consumer, isolate your code from the implementation using an adapter if the implementation doesn’t provide an API tuned to your needs. This adapter can do the translation that’s necessary, even making multiple calls, if needed, to get the information to better report to the user.
There’s more to software development than writing instructions the computer can understand.
hey, ummm, if you read this and you've got a moment ... Could you let me know. I'm trying to switch to squarespace and I think it's working.
Here's an exercise for the leadership - expand this simple backlog and track it until the project is completed - the project is to launch a team.
Goal: lauch a new team; success criteria - doing sprint 1 and releasing a product increment
- An "Order" to create team
- Business to deliver Purpose / Vision for new team
- Team Roster
- Team Infrastructure
- Mutate Wishlist into a Product Backlog (visible to team, sized, prioritized by delivery order)
- Team Launch Workshop
I decided, today, to dump typepad, the blogging platform I've been using since February 2004, because it hasn't improved much since about 2008.
I'm now using Squarespace.
Here, just out of interest, is my first blogpost ever:
Hello. This is the first entry in my professional weblog. My name is Clarke Ching. I am a New Zealander but I live in Scotland with my Irish wife Winnie and Scottish daughter Aisling (pronounced Ashling). My professional interests are Theory of Constraints and agile software development. I am just a few months away from finishing an MBA in tecnology management with the Open University. I currently work as a systems analyst for a large financial organisation, although in the past I've developed in Cobol, C, Visual Basic on IBM mainframes, Unix and PCs, I've managed projects and had a brief (and barely profitable) stint as an independant consultant. This blog will focus on Theory of Constraints and software development topics, with the odd recipe and amusing link thrown in.
Clarke Ching A kiwi in Scotland
A bit has changed since then. I now have 2 daughters (Aisling 11 and Alice 8). I've long finished my MBA. I now work as an Agile evangelist/leader/change-agent for a different large financial.
We've also been corresponding with four-star General Barry McCaffrey, my former classmate at West Point. He was very clear in his comments on our new book, Scrum: The Art of Doing Twice the Work in Half the Time.
“Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”
In the process of writing our online course Agile Defense we read with great interest the Interim DoD Instruction 5000.02. This document shows at least one way the DoD is thinking about doing, Agile development in software.
Here are their two models of software acquisition. The first reflects a certain amount of waterfall thinking:
"Figure 4 is a model of a program that is dominated by the need to develop a complex, usually defense unique, software program that will not be deployed until several software builds have been completed. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds."
Here's a new, more Agile model of deployment:
"This model is distinguished from the previous model by the rapid delivery of capability through several limited fieldings in lieu of single Milestones B and C and a single full deployment. Each limited fielding results from a specific build, and provides the user with mature and tested sub-elements of the overall capability. Several builds and fieldings will typically be necessary to satisfy approved requirements for an increment of capability. The identification and development of technical solutions necessary for follow-on capabilities have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly."
The new model moves the DOD closer to the second value in the Agile Manifesto - working product over comprehensive documentation. They may not meet the Agile Manifesto principle of delivering product increments in a few weeks to a few months. Yet it is a definite step forward.
At the Pentagon I emphasized that DOD purchasing should require "Change for Free" in all their contracts as it could save them hundreds of billions of dollar a year. The F-35 contract alone is $143B dollars over budget mainly due to software testing!
Sign up for our online course next Wednesday from 11-12 for more on how Scrum, Agile, and the military work together.
If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.
That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.
In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.Feedback is Necessary
Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”
This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.
Each team must know the principles:
- You need to see all the work in progress.
- You want to flow work through the entire team.
- You want to see working software, sooner, rather than later.
Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.
Now, let’s talk about what happens when you want to meld these teams into a program.Each Team is the Heart of the Program
You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.
The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.
This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.
In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).
That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.
Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.What If the Teams are New to Agile?
What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.
If your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.
However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?
That is much more difficult.
Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.
You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.
Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.
When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.
They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.
What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?
Don’t panic! You work in ways to reduce your risk.
Stay tuned for Part 5.
In my last blog post on the different types of power (here), I noted that it is more advantageous to focus on increasing expert and referent power than the other power bases. I’d like to look at this in a bit more detail here.
Power bases may be divided into two categories
- positional, i.e. situations where a person is in a position to have power
- personal, i.e. situations where a person’s power is intrinsic in nature
Reward, coercive, and legitimate power are all positional in nature. To have them, one must be in a position to reward or coerce, or to have legitimate authority. Raven’s later addition, information power, is also positional in nature (Raven, 1965). Personal power bases are, in a way, easier to increase, as the effort required is purely personal, and does not always require outside help. This being said, which of the 2 personal power bases should one focus on increasing?
Benfari et al. (1986) define power relatively simple as “the capacity to influence the behaviour of others”. For them, power is value-neutral. Power is also interpersonal; it requires (at least) two individuals, whose power interactions may be reciprocal or one-sided. For individuals, power exists as two aspects: as a motive, and as a behaviour, and either aspect may be disturbing to the person(s) on the receiving end.
The need for power exists in all of us to a greater or lesser degree. Simply having control over one’s own life is a form of power. Problems start when the urge for power increases, when the desire for power becomes a motive or driving force for someone’s actions, up to the point where it becomes pathological (e.g., as seen in too many politicians). When power is exercised and manifested as influence, it becomes a behaviour in itself. Even though power may be value-neutral, the response to power actions may be positive (P+) or negative (P-) for the recipient, and will thusly change the recipient’s view of the wielder of the power. For example, consider expert power. We have all profited at some time from the advice of an expert, but how often have we experienced someone flaunting his expertise as a know-it-all?
The recipient views the power as negative if he feels a sense of being exploited or manipulated. If the recipient views the power as positive, i.e. when the recipient benefits from the power, he feels support, increased motivation, and an ego boost.
Different types of power have different positive and negative aspects. Reward power is only positive, coercive power only negative. Benfari et al. list 7 types of power – in addition to the 5 classic types described by French and Raven, they include Raven’s information power, and add what they call “affiliation power”. This type of power is similar to the concept of centrality in social network analysis (Bonacich, 1987), and describes the power a person has by virtue of their access to other persons of power, by being affiliated with them. (n.b. Benfari et al. also mention the power of groups. Since this is not an individual power base, we’ll look at it in a later post, but not here).Power base Explanation Perceived as Reward Positive strokes, remuneration, awards, compliments, other symbolic gestures of praise P+ Coercion Physical or psychological injury, verbal and non-verbal put-downs, slights, symbolic gestures of disdain, physical attack,demotion, unwanted transfer, withholding of needed resources P- Legitimate Management right to control, obligation of others to obey, playing ‘the boss’ and abusing authority P- Exercise of leadership based on authority in times of crisis or need P+ Referent Identification based on personal characteristics, sometimes on perception of charisma; or reciprocal identification based on friendship, association, sharing personal
information, providing something of value to the other, and on common interests, values, viewpoints and preferences; creation of reciprocal ‘IOUs’ P+ Expert Possession of specialized knowledge valued by others, used to help others, given freely when solicited P+ Unsolicited expertise, seen as unwarranted intrusion; continual use can create barriers; expertise offered in a condescending manner can be seen as coercive; withholding expertise in times of need P- Information Access to information that is not public knowledge, because of position or connections; can exist at all levels in the organization, not just at the top; those at the top may know less about what is going on; secretaries and personal assistants to senior executives often have information power, and can often control information flows to and from superiors P- Affiliation ‘Borrowed’ from an authority source with whom one is associated – executive secretaries and staff assistants act as surrogates for their superiors; acting on the wishes of the superior P+ Acting on their own self-interest; using negative affiliation power by applying accounting and personnel policies rigidly P-
Source: Based on Benfari et al. (2001)
As can be easily seen from the table above, the only types of power that are considered purely positive are reward and referent power, and of these, only referent power is personal-based. This provides a good argument for a focus on increasing referent power if you want to be able to help your clients’ teams, and co-workers. In my last blog post, I mentioned a number of core competencies to concentrate on for increasing referent power. Here are some other tips from Benfari et al.
- Get to know the motives, preferences, values and interests of colleagues.
- Build relationships using shared motives, goals and interests.
- Build large networks of people and information – make connections between individuals and between individuals and different stakeholders.
- Respect differences in interests, and points of view-don’t attack – invite reciprocity.
- Give positive strokes, use reward power, confirm others competence.
- Share information and expertise with others.
- Minimise concerns with status.
- Develop communication skills – assertiveness, meta-communication, question asking, clarity and rapport.
- Manage your impression – dress, body language, facial expression, voice one, etc.
- Develop understanding of how people tick – e.g. body language, use of language, ‘trigger points’.
- Develop an understanding of systemic deep dynamics and implicit information channels – know what you are sitting in in any given moment.
- Demonstrate congruence between espoused values and behaviours.
- Develop ability to take risks and lead on issues – even if it is lobbying for an idea within a meeting.
Sounds like good advice for anyone wanting to become a better ScrumMaster, doesn’t it?
Benfari, R.C. et al. (1986) The Effective Use of Power. Business Horizons, 29, 12.
Bonacich, P. (1987) Power and Centrality: A Family of Measures. The American Journal of Sociology, Vol. 92, No. 5, 1170-1182.
Raven, B.H. (1965) Social influence and power. In Current studies in social psychology, (Ed, Steiner, I.D.F., M.) New York: Hoh, Rinehart. Winston, pp. 371-381.