We all want to perform well at work and live a fulfilling life. It all gets down to these two simple needs. If we take a minute to contemplate that a bit more, those two simple needs further get down to a few simple actions. I’m writing this for those folks who work in offices at computer screens: software developers and others.#1. Get enough good sleep
Big things start with simple habits. The heroic sagas about office super-achievers used to have it that sleep is an annoying waste of time, and people should cut down on sleep wherever possible. Turns out, sleep is vital for our well-being and performance, here’s just one article to confirm that. Let alone researches, from what I’ve personally observed, some people can sleep for 8 hours straight, while some sleep in chunks, waking up for several times per night. What matters most about sleep is that we work in offices. We are not construction workers, who are able to wake up simply by staying outside, and doing physical work. Anyone whose work involves staring at a screen and thinking will not get away with it. If your body wants to have its share of sleep in chunks, you have to attend to it. No hacks will do the trick. All our problems with health, and hence with performance, are rooted in the careless attitude to the way we sleep. The earlier in life we start taking care of our sleep, the better our chances for long-term viability at delivering good work.#2. Re-think your commute to work
You woke up in the morning. You didn’t have enough sleep, for one reason or another. Your morning commute will then add up to the impending stress of the day. We somehow take it very lightly when our doctor says that we need to avoid stresses, and we keep on driving in congested areas, stressing ourselves out in bad traffic jams. If the commute takes more than half an hour, and this happens continually, you need to re-think your approach. Either find a way to work remotely, or at least drive to the office only several times per week. We’re doing better with letting people work remotely, looks like. Unless there’s some compelling blocker that makes you burn your life in excruciating commutes, consider staying away from them altogether. It might seem that we’re fine putting up with such things as bad commute or bad sleep. However, as we get beyond our mid 30′s, all those small stresses build up and insidiously sabotage our performance. For someone whose work is to cut wood in the forest this all is not that bad. They’d get their share of fresh air and release their stresses via muscle work. Unfortunately, we can not do that as knowledge workers. Even if we work out in the gym, the larger part of our day is spent sitting in a chair, and there’s no natural way to release this stress. Bad commutes add up to this unreleased tensions working like a delayed-action bomb that ruins us from inside.#3. Work in comfortable office space
Our stress ball is rolling on. Office is next in the line. Is your office customized to your individual needs? If you feel that you need fresh air, and not an air conditioner, or some green plants around you, or more control with artificial lights turned on or off when you want them to, fight for it. If your office looks rather like a farm for kettle with open space and no space for privacy, run away. We are where we spend our time. Harmonious environments endow us with the ability to think clearly, decide justly and work effectively. Office space and how it is tuned to your individual needs is another major component to sustainable performance.
This involves interactions that we have with co-workers, whether work-related or not. We simply need to work with people we like. Besides, a comfortable personal space at work includes smooth communication flows. If we recall how many times per day we need some information to proceed with our work, smoothly, and what a roadblock to productivity it might be when we are not getting this information in time, then we need to write off those times that we spend idling and heating back up. That’s great if a software developer or a QA engineer can sink into a monk-like state meditating in front of their screens, requiring no input from anyone else. However, if your work stretches beyond solitary meditations, you’re most likely to interact with other co-workers, and it’s in your best interest to fine-tune those communication flows, especially if this is a remote collaboration. Arranging comfortable personal space at work also involves a smart approach to meetings. If you see that all those many meetings deliver a low ROI on the time spent, flag this to your co-workers.#5. Work with comfortable tools
Count all those occasions when you have mini-bummers as your tools won’t let you do the work comfortably, keeping your flow. Are you struggling to build this dashboard that you need in this reporting software? Or retrieving a report that would show all the details about a project progress? Our performance is very much influenced by the tools that we are using to do the work. If a project management tool, or any other digital app that you use is continuously giving you hard time, fight for the tools that help you do the work.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
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?
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!
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.
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
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.
User Story Checklist
Table 1 shows a checklist of typical tasks and tests in a user story. This should help a cross-functional agile team to pay attention to all these tasks and tests and not miss any work for the story in order to complete it and get it accepted by the product owner. If a story requires multiple design and code development tasks and multiple acceptance tests, more tasks and tests can be added to that specific story than shown in Table 1. Some tasks in Table 1 are optional, and may not be needed for a specific story.
Table 1: Tasks and tests in User Story ChecklistDefect Checklist
Defects found, especially outside a sprint such as in production, can be logged with the following checklist of tasks and tests.
- Task: Log the defect with steps to reproduce the defect: QA tester
- Task: Analyze and debug the defect: Developer
- Task: Fix the defect: Developer
- Task: Specify the test to verify the defect: QA tester
- Test: Execute the test to verify it: QA tester
- Task: Close the defect which has been verified as fixed: QA tester
Epic Breakdown Checklist
This checklist is based on the work done by Richard Lawrence where he recommends 9 patterns that you should try to use to break down an epic (a large story or feature) into smaller user stories. I have listed these 9 patterns as options below. A customized checklist augmented with a brief example for each pattern suitable for your organization will be very handy and effective when it comes to breaking down epics into stories.
- Option 1: Workflow Steps
- Option 2: Business Rule Variations
- Option 3: Major Effort
- Option 4: Simple/Complex
- Option 5: Variations in Data
- Option 6: Data Entry Methods
- Option 7: Defer Performance
- Option 8: Operations (e.g., CRUD)
- Option 9: Break Out a Spike
Sprint Planning Readiness Checklist
This checklist consists of a list of preparatory tasks that should be completed before starting a Sprint Planning Workshop or Meeting. These tasks should be completed ideally one timebox ahead, i.e., in parallel with the previous sprint execution. Completion of these preparatory tasks will help ensure a highly effective and productive sprint planning workshop, which is a time-boxed event (1/2 day for a two-week sprint or one day for a four-week sprint).
- Task: Define the Agile team, its members and their roles/responsibilities: ScrumMaster
- Task: Draft the key objectives for the upcoming Sprint: Product Owner
- Task: Define and create the project hierarchy in Agile Project management (APM) tool, and make sure the members of the Agile team have the right role assigned on the project: ScrumMaster working with APM tool administrator
- Task: Create the Sprint backlog in APM tool: Product Owner working with Business analysts: Epics, stories (preferably satisfying the INVEST criteria, Defects, Spikes, Maintenance work, porting work, certification work, Regression testing, System testing, Performance testing, etc.
- Task: Explain and clarify the sprint backlog to team members for the upcoming sprint by conducting one or more sessions one timebox ahead, i.e., sprint work done in a pipeline mode (see details in my blog on Is Your Sprint Pipeline Running Well?): Product Owner.
- Task: Calculate agile capacity for the team and each team member for the upcoming sprint (for capacity-based sprint planning – see details in my blog on agile capacity calculation): ScrumMaster working with each team member
- Task: Prepare the preliminary rank order of backlog items based on business value (Optional): Product Owner
- Task: Make sure all IT environments are in place: ScrumMaster working with IT staff: Development, QA, build machine, continuous integration server, software licenses, test data, any special hardware needed
- Task: Review the Sprint Ready checklist (see below) and take necessary actions so the Agile team will be 100% ready to start the sprint as soon as the Sprint Planning Workshop is over: ScrumMaster.
- Task: Complete all logistical arrangements for Sprint Planning Workshop (venue decided, attendees identified and invited, workshop material arranged, food ordered, etc.): ScrumMaster
The checklist shown in Table 2 consists of a number of tasks (Tasks T1 through T14) to be completed during a Sprint Planning Workshop. Rough time estimate for each task is indicated for a typical three-week sprint planning being done for the first time. With process maturity, experience and well-jelled teams, this planning time should come down to ½ day for two-week sprint planning to 1-day for four-week sprint planning.
Table 2: Sprint Planning Workshop Checklist
Sprint Ready Checklist
This checklist consists of a set of tasks that must be completed before a sprint should start and can run smoothly. If there is major incompletion of any of these tasks, it would be premature and risky to start a sprint, as it will experience obstacles, hick-ups, delays and impediments.
- Task: Sprint objectives are well defined: Product Owner
- Task: Full inventory of all work items is available, and all tasks and tests in stories of the sprint backlog are properly defined and have proper estimates: Product Owner, ScrumMaster
- Task: Acceptance tests for each User story are well defined: Product Owner, QA tester
- Task: All Agile team members are identified, their roles defined and necessary training completed or plans made: ScrumMaster
- Task: Individual and total capacities and Individual and total estimated efforts match (for capacity-based planning): ScrumMaster
- Task: Various standards (coding, testing, documentation, build, user interface, compliance, etc.) for your project are defined and easily available: ScrumMaster, Team Leads
- Task: All IT environments, infrastructure and test sets required for the Sprint are available: ScrumMaster and IT staff
- Task: Work is distributed evenly across all members of Agile team (load balancing done): ScrumMaster
- Task: All stories in the Sprint are linearly rank ordered: Product Owner with Team
- Task: Sprint Done Checklist is well defined: Product Owner with Team
- Task: Any remaining small tasks that must be completed to reach 100% Ready state are documented (and are not show-stoppers): ScrumMaster
Daily Scrum Checklist
This checklist consists of a set of tasks for each individual member and also for ScrumMaster. See specific details in my blog on Daily Scrum.
- Task: Ensure that the Daily Scrum room venue and timing is the same for every day in a sprint: ScrumMaster
- Task: Invite each member of the Agile team for Daily Scrum on a standing basis for every day throughout the sprint duration: ScrumMaster
- Task: Prepare for the Daily Scrum meeting ahead of the actual meeting: Each team member
- Report on the status of yesterday’s tasks against the plan for yesterday
- Present the plan for today’s tasks
- Present what do I need from any other team members to do my work
- Present any impediments on the horizon that could block my work
- Task: Present key information radiators from APM tool, such as burn-down and burn-up charts, Cumulative Flow diagram, Impediments being worked on: ScrumMaster
- Task: Capture any risks, issues, and decisions coming out of Daily Scrum: ScrumMaster
Sprint Done Checklist
This checklist consists of a set of tasks that must be completed before a sprint can be declared successfully “Done”. This list ensures unambiguous completion of a sprint.
- Task: Acceptance testing completed: QA testers
- Task: Defect fixing work completed: Developers
- Task: Fixed defects are verified and closed by QA members of the agile team: QA testers
- Task: The list of defects to be pushed out to the next sprint is finalized: Product Owner, ScrumMaster, Team
- Task: All technical documentation is completed: Technical leads
- Task: All user documentation is completed and is ready to be released to sprint users: Tech writer
- Task: Sprint release can be delivered to interested customers and users ready to receive it: ScrumMaster
- Task: All data in APM tool is up-to-date and consistent with the completion (Done) state of this sprint: ScrumMaster and Team
- Task: Sprint delivery has met the Sprint objectives: Product Owner
- Task: Sprint release is accepted by the Product Owner: Product Owner
Sprint Retrospective Checklist
This checklist consists of a set of tasks that must be completed during Sprint Retrospective session (typically a 1 to 2-hour timebox) so that the team can develop a SMART action plan that it can act on during the next sprint to improve its own agile process in a specific way. See specific details in my Sprint retrospective blog.
- Task: Determine up to 3 top things that worked really well, and the team wants to continue: Team
- Task: Determine up to 3 top things that were most problematic, and the team wants to discontinue or change: Team
- Task: Determine up to top up to 3 impediments and their root causes: ScrumMaster
- Task: Capture and present key statistics, such as initial capacity of the team, planned vs. actual velocity, scope change. Most of these are reports generated by APM tool: ScrumMaster
- Task: Develop 3 to 5 specific action items as part of the Specific, Measurable, Achievable, Realistic, Time-bound (SMART) action plan to improve the agile process: Team
- Task: Convert the SMART action items into Stories in APM tool, and assign them to the next sprint: ScrumMaster
Need more information?
By no means, this is neither a complete set of all agile checklists nor I am suggesting that all agile development work can or should be captured into checklists. However, you may think of several recurring activities with some degree of complexity as good candidates for checklists. Some examples: Daily Builds, Compliance and Certification Testing, Customer Trial and Evaluation Testing, Customer Acceptance Testing, Release Packaging, Delivery and Deployment, Customer Support Calls, etc. Even the well-known INVEST criteria can be thought of as a checklist to make sure that stories in a backlog are Independent, Negotiable, Valuable, Estimable and Testable; and the SMART tasks within each story as another checklist for tasks that are Specific, Measurable, Achievable, Relevant and Time-Boxed.Agile checklists can also be used as an effective mechanism to plan, coordinate, align and synchronize work across a larger number of agile teams on a large-scale agile project, such as a program or a SAFeTM release train of 5 to 10 agile teams working in synchronization on the same cadence, and a set of programs constituting an agile portfolio of several hundred people. Dean Leffingwell’s book on Agile Software Requirements presents a very comprehensive Release Planning Readiness Checklist in Appendix C. A Wikipedia section on Non-Functional Requirements (NFRs) gives a fairly comprehensive list of NFRs to consider. You may use that list as a checklist to minimize the probability of overlooking or missing one or more NFRs while preparing and grooming your product backlog. The benefits of agile checklists increase even more when you want a large number of team members on multiple teams of a large-scale agile project to do their coordinated work in a consistent, standard way, and to avoid unnecessary variations among different teams and their members when there is no reason of or benefit from those variations. Thus is the case because larger scale projects create additional complexity due to the need for aligning and synchronizing multiple teams in a program and managing a number of programs into a cohesive portfolio. An APM tool like VersionOne can make it very easy to templatize these checklists so all items within each checklist can be modeled as tasks and tests in a template; then those tasks and tests can be completed in a consistency way without errors across a large number of people and agile teams. A team can have its own set of checklist templates, and projects and programs can have their own checklist templates, in addition to a standard set of checklist templates that are common for all members, teams, projects and programs in an enterprise. If you are not yet using an APM tool that supports templates, don’t let that stop you from using agile checklists. Try using Excel files on SharePoint or spreadsheet docs on Google Drive for creating and maintaining your checklists. That will get you going quickly.
For additional information on agile checklists, you may find VersionOne agile checklist white paper very informative and imminently actionable.
Have you tried checklists on your agile project? What is your experience?
Are you interested in experimenting with your own set of checklists?
I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).
Bugsnag is a web and mobile error monitoring application that detects and diagnose crashes within your applications. They recently informed us about their new Assembla integration that can create Assembla tickets for detected errors allowing your team to quickly start squashing these errors via Assembla tickets.
To set up this integration, you will first need to have a Bugsnag project up and running. To try Bugsnag out, you can sign up here. From your Bugsnag project, visit the Settings > Notifications section to enable the Assembla integration. Once enabled, you will land on the integration configuration page that look like this:
Determine when an Assembla ticket should be created: when the first exception of a new type (error) occurs, when a previously resolved error re-occurs, and/or when you manually click on “Create Issue” on an error within Bugsnag.
Space URL: Such as https://www.assembla.com/spaces/space_name/tickets
Your API Key and API Secret: This can be created in your Assembla profile sidebar menu, or by following this link.
Tags (optional): This provides a default tag for all Assembla tickets created from Bugsnag such as “Bugsnag Error.” I personally love this part of the integration because with tag filters, you can easily see all errors that are being worked on and where they stand. To learn more about Assembla’s tag feature, check out our release announcement.
To learn more about other companies that have integrated with Assembla or to submit an integration for review, check out www.assembla.com/integrations.
With the recent file search improvements, it is now easier to find the files you are looking for when you need them. With every file upload, we now index all the following elements: file name, tags, mime-type (media type), and author.
- File Name: We now apply a word delimiter filter that splits words into subwords based on intra-word delimiters such as case transitions ("PowerShot" → "Power", "Shot"), letter to number transitions ("SD500" → "SD", "500"), and characters ("Wi-Fi" → "Wi", "Fi").
- Tags: If you add the optional tags to a file, you can easily include a tag in the search parameters to locate the file.
- Mime Type (Media Type): When a file is uploaded, it will be indexed with a media type such as hello.png will include “image/png” so it can be found with a search for “hello” or “image” or “png” or any combination like “hello image.” Almost all files have a mime type such as word, excel, zip, pdf, etc., and we now index them so you can locate your files easier.
- Author: The author field consists of the user’s first name and last name as displayed in their profile as well as username. Usernames are also use the same word delimiter to split usernames into subwords. So if John Smith with username JohnRocks uploads a file, you can search for that file with “john” or “smith” or “johnrocks” or even just “rocks.”
Most importantly, the default logical search operation has changed to search for words using AND instead of OR when using a combination of words. For example, when you search “john image” it will return back anything that is an image AND that was uploaded by John.
We hope these improvements make file searching more efficient. If you have any other suggested improvements, please let us know on our feedback site.
Check out some other Assembla tips and tricks!
It’s OK – I do too.
I also enjoy reading a well-researched article in, say, the Harvard Business Review or the Wall Street Journal that validates what we do every day in the Lean-Agile community. It shows that they want what we got (and sometimes, vice versa).
But I recently happened across the April 2011 issue of Real Simple magazine, the riveting theme of which was “Spring Cleaning”. My curiosity as to how that subject could possibly warrant an entire issue led me to thumb through the pages until I came across an article entitled “This is Your Brain on Procrastination”, written by Amy Spencer.
The article presented the following list of things to do in order to get important things done around the house:
- Do the worst thing first (you won’t have the energy to do it later)
- Start your day over at 2:00 PM (assess and adjust regularly)
- Make the job smaller (and do it just “good enough”)
- Create an audience (make yourself accountable)
- Race the clock (see how working in short, timed bursts affects your productivity)
- Don’t interrupt yourself (or let anyone else do so)
- Plan an unprocrastination day (prioritize and then immediately DO)
Sound familiar? I thought so, too.
Yes, three years ago, guidance for which people still pay good money to be Agile-certified was published in an article on getting ahead on household To-Dos. That tells me that maybe Agile isn’t so special anymore.
I think that’s actually a good thing.
Why? Because I noticed a long time ago that most of us tend to use one system of thinking at home, and another when we’re at work. It’s almost as if we swap brains somewhere between the front door and the driveway.
For example, Home Brain says, “I have only so much money and so much time, so I’m going to have to accept the fact that I can’t have both a new refrigerator AND a new fence.”
Work Brain says, “Based on our best information, I know we can only really do the fridge. Tell you what: I’ll throw the fence in as a ‘stretch goal’.” (Home Brain’s too smart for that. He knows what stretch goals turn into.)
My efforts over the last several years, to a great extent, have been focused on simply getting people to take their Home Brains to work with them. The addition, now, of even informal Agile thinking to Home Brain’s innate clarity and common sense will make it that much more valuable at work.
So what if Agile’s mysteries are being divulged to the uninitiated as they stand in the supermarket checkout line? If value-oriented and throughput-focused thinking can permeate such mundane areas of our lives as decluttering a closet, then the the way we are trying to shape how we think at work will become more similar to how we think at home.
That should make bringing an Agile mindset into the workplace more natural. I’m OK with that, even if it means Agile loses some of its status in the process.
I gave a talk at Agile Coaches Exchange meet up yesterday and someone emailed afterwards saying
"Rachel mentioned about few questions that she uses during one on one. Those set of questions could help me a lot because I am terrible to start and flow the conversation with my team."
So I thought it might be handy to do a quick write-up of what questions I tend use in individual coaching sessions.
Well just to be clear, I don’t follow an exact format or set list of questions -- I’ve been coaching for so long that questions seem to come burbling out of my mouth without much premeditation or forethought. Here's what I think I ask but this might actually differ a lot depending on the person or current issues.
Before we head off to our meeting, I check “Is now a good time for you?” and I’m fine to move to another time or skip the meeting. Coaching is always optional.
Once we sit down, I tend to start with open questions like:
- “How are you doing?”
- “Are things going well at the moment?”
- “Are there any issues you want to discuss?”
This tends to open out topic areas that we kick around -- discussing root causes , trying to see events from other perspectives and identifying possible courses of action.
I also look back in my notebook to see whether we talked about any specific issues at our last meeting:
- “Last time we discussed pair rotation in your team, is that working better now?” or
- “You facilitated a retrospective for the ABC team last week, how do you think that went?”
If they led a meeting, I ask if they’d like any feedback from me.
I might also mention current events such as team or process changes:
- "We have a new developer joining your team next week, have you thought about how she's going to get to know the system?"
- "We've changed the story time meeting format to run it with both teams together, how do you think that's working out?"
If the conversation dries up then we move onto specific areas such as personal development:
- “What research projects/Gold Cards have you been working on lately?”
- “Got any plans to give a lightning talk about that next week?”
- “You mentioned that you were planning to submit for XYZ conference, have you sketched out an abstract?”
I usually check at the end “Are there any other things you wanted to discuss?” and let them know that I’m around to discuss further any time.
There are no magic words or special incantations that I’m aware of. The main thing is to focus on what the other person has to say and try to listen carefully to what they’re experiencing and changes they wish for. I care about whether they’re happy at work and hope that talking will help them stop worrying about things that are holding them back and start acting on their concerns and ideas.
I’ve never been much of a blogger. The concept of short but frequent commentaries on subjects causes the perfectionist in me horror. I hate failing on a deep visceral level. Even my small failures tend to cause me distress for weeks or months after whatever the mistake was.
My personality tends to stop me from starting things that may fail, but others deal with failure in other ways. Some try to hide the failure, others deny that a failure is actually a failure and continue to go along without making any sort of correction.
In business today my personal preference for failure avoidance is typically not an option. If we don’t do anything we don’t make money and we are probably involved in defrauding investors somewhere along the line, so we will just brush that one aside for the moment. The other two are the ones that I would like to address, because these are what Agile and very specifically Scrum looks to help us overcome.
This difficulty often results in failure, as it should. Sadly the reaction to this failure is all too often; “We can’t do this” when it should be “How can we make this work”. The software industry has clearly demonstrated that Scrum is not only possible, but optimal. There is no business that Scrum could not be applied to successfully (should it be applied is another debate).
In truth, dealing with the problem of an organization trying to hide failure is a simple one, all you have to do is practice Scrum and everything will surface. Dealing with the denial of failure is a bit trickier.
In most software organizations we are conditioned to be horrified by failures because in a traditional waterfall structure they are catastrophically expensive. At best we have lost months of work, and at worst, years. Scrum allows us dramatically reduce the impact of these failures by taking them to a place where we have lost 2 weeks at most, or more typically a day or two. The trick is that even though these failures are not costly, our reaction to them is the same as if they had been. We don’t see them as the valuable knowledge growth they represent; we see them as the end of the world.
In any sort of bureaucracy the instinct to hide or deny is strong, but if we can bring people around to an understanding that failures are simply part of the normal course of business, to be learned from and used to drive adjustments, we can start to overcome the denial.
In the end it is all a culture shift. Adopting Agility in an organization requires self-reflection, asking ourselves why we react as we do to failures. Admitting that aspects of our business that we just assume to be “normal” are actually failures and should be addressed comes with this. It’s a frightening thing to put together a proper list of impediments to success, but a necessary one.
Scrum shows us what is wrong, but we still have to fix it. The final, and most important piece of this is understanding something that years of conditioning has destroyed in most organizations; Just because something is broken doesn’t mean we have to fix it today, or ever. Part of why we hide, avoid, and deny failure is because we think that as soon as we know about it we have to fix it. Not true, not even possible in most cases. We have years, decades even, of problems to resolve, it’s going to take a while, but if we don’t dredge them up, admit to having them, and work out a plan for fixing them, they never will be.
The post Grasping Agility: Agility, Personality and Failure appeared first on blogs.collab.net.