agile42 Thought Leadership at Scrum Gathering Phoenix 2015

/by

We’re pleased that agile42 coaches are leading five sessions at the Scrum Gathering 2015 in Phoenix on May 4-6, 2015

  • Estimating is NOT planning by Dhaval Panchal  (Monday May 4th, 10:45 – 11:30)
  • Getting Your Team from Good to Great, by Brad Swanson (Tuesday May 5th, 9:00 – 10:30)

We’re looking to seeing you there. Follow along on twitter: #SGPHX

 

Innovation, Lean, Agile. Myths and Misconception

/by

Lean Kanban Southern Europe is a conference very close to our heart since we organized LKSE14 in Bologna last year. This time, LKSE15has been organized with the usual passion by our Spanish friends in Madrid and I have been very happy to present a talk there focusing on the relationship between Innovation, Lean and Agile.

While LeanKanban and Agile introduced disruptive innovations in the “way of working” their main focus however was not on product innovation: the Agile Manifesto premise is that it is about “better ways” of developing software, Kanban first steps happened in a product maintenance context.


LeanKanban and Agile are nevertheless contributing more and more to innovative product and service creation.

During the talk we saw how this is happening, sometimes through influences and contaminations with/from disciplines like Systems Thinking and Complexity Thinking, approaches like Kanban Portfolio Management or, at a different level, Lean Startup and Lean UX.

At the same time we looked at “myths, misconceptions and misuses” that can lead to painful mistakes and failures and made the title of the presentation. Here are the slides of the talk and the video thanks to AutentiaMedia.


Siemens

The word from Finland, Agile development at Siemens

/by

The Finnish magazine Tekniikka & Talous has published a great article by Tero Lehto on the agile advancements at the electronic giant Siemens. The article describes how agile development is becoming more common in the industrial equipment sector. It also tells about the benefits Siemens is reaping after investing into agility.

Siemens Motion Control deployed agile methods end-to-end from product management to developers. Through targeted pilots involving multiple teams, they grew and are now continuously improving their own just-in-time portfolio management system that fits and supports their strategy. Thanks to a much faster time to market, they have now cut the development time from 2–3 years down to one year. This reduces the inventory of committed work and allows them to react quickly to feedback and change requests.

Coaches and trainers from agile42 Finland participated in the early stages of the transition at Siemens. agile42 has extensive experience of agility in embedded software and hardware development. We have covered the topic before.

 

Article from "Tekniika & Talous"

What Is Agile?

/by

 

In 2010, CIO Magazine identified 3 global technology trends that would change how companies used technology: Cloud Computing, Mobile and Agile. All of these trends have grown into major movements, and while Cloud Computing and Mobile are prevalent and used at a consumer level, agile methods are often confused with being flexible and nimble methods that are light-weight at best, chaotic and undisciplined at worst, rather than disciplined iterative and incremental methods.

Today, over 80% of IT departments say they are using agile methods to deliver at least some IT projects, up from 49% just a few years earlier.

But what exactly is an agile method, and why are so many companies adopting agile methods?

An agile process is one based on short iterations of work delivering incremental value to the end-customer often, preferably at the end of every iteration.

In software delivery, this typically involves teams of 7-9 people working on few small features during short iterations of about 2 weeks, and being done to publish features for customers use. 

Iterative and Incremental delivery on short 2 week cycles is often challenging and requires discipline in engineering and management practices. There are many myths surrounding Agile methods.

One of the more common is the idea that Agile means ‘I don’t need to document or plan’. In traditional project delivery about a third of the time is spent planning and documenting the requirements to be delivered so that these requirements can be handed to the delivery and testing teams to work on. The planning and documentation is intended to track and handoff information. In an Agile team, the planning and requirements definition are broken down into small pieces that are collaboratively discussed and agreed with the team. Rather than “all-in” up-front planning at the start of project, Agile teams plan throughout the project delivery. Planning for small increments, one iteration at a time. This allows Agile teams to learn from previous iteration and apply their new found learning to better delivery of software in the following iteration.

Agile builds in a learning-engine that enables a team to expose organizational challenges. It took many years for your organization to come to be this way, it will not magically transform itself into delivering “working software” every two weeks. Management maturity is crucial in being able to learn from their Agile team’s experiments. Recognizing failures as learning opportunities, allow management teams to incrementally peel through the layers of dysfunction that has come to clog your organizations delivery capability. At agile42, The Agile Coaching Company – we pride in our ability to help organizations navigate through the uncomfortable challenges ahead. Much like Samwise Gamjee (Lord of the Rings) we know that the burden is not ours to carry, but we will be right by your side all along the way.

 

 

 

DevOps Metrics: Lies, Damned Lies and Statistics

/by

There are tons of metrics available for IT Operations. ITIL mandates/suggest a number of them. They can be related to Technology, Process, People, Service. But are they really needed? The good news: in general only a few. The bad news: every context is different and you will have to understand on your own which are relevant for you – and they should (better) change over time.

Metrics and KPIs may (do) foster bad behavior. It’s pretty easy to cheat and lie about numbers and statistics. As the say goes “tell me how you measure me and I will tell you how I behave”. This is true in particular when numbers are used for performance reviews and for local optimization. Agile and Lean have a lot to say about metrics and why and how they should be used.

At the Italian DevOps Day 2015 in Bologna I discussed with the audience some of these. Here are my slides and pointers.

body river surrounded by dress

Managing Flow

/by

My next blog post is about “Managing Flow”. So many organisations I work with have benefited from using this technique to improve how they do what they do. I also felt it timely, since this is a key practice in Kanban, and Klaus Leopold will be coming to SA in May to provide two awesome two day courses on Kanban fundamentals, and scaling.

Traditional project management teaches us to manage resources and dependencies. Making sure everyone is busy is important because our plan is based on people optimisation and cost accounting. Managing flow in Kanban is the opposite of this and therefore often counter-intuitive.

Managing flow is a principle of Kanban and is about shifting the focus from the people to the work. So instead of managing people and keeping them busy all the time, we focus on managing the work and understanding how we get that work through the system faster.

The distinction is very important.

How do you manage flow?

Visualise

Well, the first step to managing flow is to understand where all the work in the system (by system I mean a human system designed to deliver value to the business) is. You need to visualise the value stream, and then visualise all the work in that value stream. Your value stream is the flow of work through your system, from concept to cash or beginning to end. This often depends on the level of granularity of your Kanban system. A good way to do this is to use a physical board, and to map your process from beginning to end. How does work flow into your system and how does it leave.

Limit WIP

Once you have the visualisation of where the work is, you need to begin to limit the amount of work in progress. Why would you want to do that I hear you ask?

There are many reasons to limit work in progress:

    • Create focus and prevent context switching: The more work there is in a system, the less focus any piece of work is getting. Context switching has a massive transaction cost and means that any single piece of work can end up taking longer than if there was focus around getting it done.
    • Decrease batch size:  Smaller batches mean faster feedback and shorter lead times.
    • Decrease complexity: The more work there is in a system the more complexity there is. Things that are deployed on the test environment affect each other. You need to manage all the dependencies that are created and the communication efforts of many more people. This all adds complexity and the higher the complexity the greater the risk.
    • Enable flow: The more work there is in a system, the more it will look like rush hour traffic and the less flow there will be. At 5:00pm in Sandton all the buildings in a four block area empty at the same time. The result of this is that the road infrastructure can’t handle the capacity and the roads become blocked and gridlocked. The same happens in software teams, and human systems when they have too much work in progress. By limiting the work in progress you can enable much better flow of work through the system.

 

Show blockages

Focusing on where the work is in a system, can help us have better conversations about which piece of work is the most important and where we need to spend our energy. It can also help us to see what is getting stuck. When something is stuck we want to visualise that. We want to understand first of all why it is stuck and second of all we want to make sure that our energy is focused on getting it unstuck. The tendency in systems designed for people optimisation is that the person whose current task is blocked by others will simply start on the next piece of work. The problem with this is that often the work item that is stuck is far more valuable than the next work item. Another impact of this behaviour, is that the ‘blocker’ gets moved into the background and forgotten about. It’s easy to forget things like that when there are another hundred other items right behind the one that’s stuck. This also means that when the work becomes unstuck it ends up in a queue, and each queue will have an impact on lead times.

Continuous Improvement

Having the visualisation, the limited WIP and the blockages visible, will give you large amounts of information about how your system works and what is in the way of getting things done. This is now a great starting point for conversations on how your system and processes can be improved and what can be done to better enable the flow of work. Talking about the work and managing the work through the system, means that we are focused on delivering value faster rather than on keeping people busy.

Keeping people busy can lead to longer queues, larger batches, more complexity and longer lead times. Managing flow will create focus on delivering value faster, and uncovering the challenges that get in the way.

If you want to know more about this have a look at http://www.klausleopold.com/.

a picture of a cell phone and parts

Techniques for Breaking Down Technically Complex User Stories

/by

Breaking down user stories to fit into a few days of work and still deliver value is a vital component of Agile and Scrum. This is what allows the Scrum team to get fast feedback on the work they are doing to ensure it aligns with customer needs.

So what happens when the Product Owner can’t break down a story any further and it’s still too big to be manageable in a sprint? This creates a very difficult problem that the Product Owner and Development Team must work together to solve. 

In this post, we’re going to break down this user story:

As a data center technician, I want to be able to configure VLANs on a network switch from a web interface so I can easily make changes to any switch without being trained on the switch configuration process.

This kind of user story can be very challenging because there are a lot of complexities and unknowns contained within it. For example, the team might know that the switch must be configured through SNMP, but may have never used it before.

Looking at the Pieces

To start us off, we need to stop thinking about the story as a single thing and start looking at the pieces. So, let’s set aside worrying about value and user stories for a moment and break down the steps.

One great way to do this is to take a stack of sticky notes and have the team draw the steps in the process of the user story on each sticky note, then put them up on the wall. This lets the team quickly brainstorm the parts of the user story together. The picture below shows how this might look for our example:

sticky notes visualization

Notice that these stay very high level. The goal is not to create a detailed plan of how this will be implemented, but rather to create a visualization of what is involved with the story. A good rule of thumb is that the Product Owner should still be able to follow along with minimal explanation from the team. This will be important for the next step in the process.

It’s also important to remember that this doesn’t have to be perfect. If some of the steps are slightly off or missing, that’s ok.

Finding the Value

Now that the team has established many of the parts of the story, we can start looking for groupings with value. This is a collaborative conversation between the Product Owner and the team to identify what will add value and what will be technically plausible.     

Grouping tasks

You can see that a few things came out of this conversation. We’ve grouped the display of switch data into one story and the configuration change into another story. We’ve also de-scoped some of the steps. The caching has been set aside, and the Product Owner understands the performance impact that has. 

We also decided that testing the change could be very complex and agreed that a simple validation would be sufficient for technicians to safely use the software, but we might keep another story in the backlog for something more robust later.

Finally, the conversation led us to realize that there might be some additional work around selecting which switch to manage as well as supporting multiple models and manufacturers. This functionality has been moved to other stories in order to provide a more manageable scope for the read and edit stories.

A Different Way to Look at Value

It is very common for teams to become accustomed to looking at value as a full feature that you can package up and sell to a customer – complete and production-ready. While not unreasonable (and not always wrong), this mindset can sometimes make it difficult to break down these kinds of stories. 

If we look at the Agile Manifesto, we don’t see any references to terms like “production-ready” or “sellable”. Instead, we see terms like “working software” and “collaboration”. So when we look for a story to have value, we want to see that we’ve created working, functional software and that it helps us collaborate with our customers and users and helps us learn something about the software we’re creating.

If we look at our groupings above, we can see that none produce documentation, mock-ups, or processes as their deliverable. For example, if we took on the update story first, we would have a simple interface that actually updates the VLAN on a given switch. This doesn’t solve the whole problem, but it lets us put real software in front of the users to see how they use it. In doing so, we may find that the user wants to see what VLANs are already trunked to the switch to select from. This not only tells us that we need an enhancement to the work already done, but it may also influence how we collect and store information from the switch in our “read” story.

Conclusion

Through this process, we’ve turned one large, complex story into five much more manageable stories:

  • As a technician, I’d like to see the current switch VLAN configuration.
  • As a technician, I’d like to be able to save new VLAN configurations from a web interface.
  • As a technician, I’d like to be able to select which switch I am managing.
  • As a technician, I’d like to be able to manage multiple switch manufacturers and models.
  • As a technician, I’d like any automated changes to be validated with robust testing.

All of these produce valuable, working software that helps us collaborate with our customers. They are now ready to be prioritized in the backlog and worked through just as any other user story.

 

Backlog Refinement – The Rodney Dangerfield of Scrum Ceremonies

/by

Seeing the Patterns

  • Have you ever been in a Sprint Planning session only to realize that the team doesn’t have enough understanding of the product backlog items (PBIs) or related requirements to properly plan the Sprint?

  • Does your team feel like they don’t have time to “waste” elaborating PBIs, learning about Acceptance Criteria, or collaboratively estimating as a team?

  • Has some manager decided that it’s “too expensive” or “inefficient” to bring the whole team together regularly and that just one or two “leads” can effectively review and estimate PBIs for the entire team?

These misconceptions and related anti-patterns are far too common when new teams begin transitioning to Agile/Scrum.

Backlog Refinement may be the 2nd most important activity (after the Retrospective) for enabling team improvement.  I like to think of it as “collaborative discovery”.  

But too often, new Scrum teams neglect it only to find themselves struggling to establish predictability, sustainable pace, stakeholder engagement or collective ownership.  The most common indicators of this neglect emerge in:

  • Painful and ineffective Sprint Planning

  • Repeated “undone work” pattern at the end of the Sprints.  

  • Poor Quality and higher Defect rates

Collaborative Discovery

The Scrum Guidei refers to Product Backlog Refinement as “the act of adding detail, estimates, and order to items in the Product Backlog”, as well as “an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items”.  Although not an official Scrum “event”, those of us with experience will come to view Backlog Refinement as a critical activity, making it both a core collaboration “event”, as well as an on-going, collaborative activity for the entire team.  

As with most recurring activities, it’s important to keep it fresh by changing up the format and/or focus from time to time.  It should always be viewed as a working session, with a clear expectation that the team concludes with some valuable outcome.  That means, sometime the focus may be on:

  • story elaboration or refinement

  • acceptance criteria refinement

  • lightweight, visual design  

  • adjusting value prioritization with technical feasibility or risk

  • relative estimation    

I encourage teams to timebox their refinement sessions to allow time to do a combination of things including, learning about new items that have emerged, elaborating items that have emerged as priorities, validating requirements for those items ready for planning and doing some form of relative estimation, like planning poker.  I also encourage the use of the INVESTii acronym/mnemonic to help them ask the questions necessary to know when they’ve reach good understanding.  My colleague Dhaval Panchal recently shared his “walk the dog” concept with me.  I love it because it provides teams with a very simple way to connect with both the functional and technical aspects of a PBI or requirement.

Teams should have a known Definition of Ready (DoR) that they have agreed to as a team that helps make sure PBIs are ready to review as a team or plan for Sprint.  If your Product Owner (assuming you have one) is too busy or disconnected from the team it can be very challenging for the team.  If you have “Business Analysts” on the team, they can often serve the “glue” between the PO and the team to help make sure the necessary details emerge in a timely manner. Include SMEs and key Stakeholders, as necessary, to make sure expectations are managed effectively.

Remember, it’s not solely the responsibility of the PO to refine the backlog. I believe the entire team should contribute to this, certainly early on, to achieve collective ownership and predictability.  This does not mean that every person must get into the details of every item. It may make sense to self-organize a few folks around – what’s valuable, what’s feasible or what’s usable.  While some will advocate that you don’t need the whole team participating in Backlog Refinement, I think new teams need this to build collective ownership and shared understanding.  More mature teams may get away with alterations to this, but be careful not to inject more risk or ambiguity by excluding team members from the conversation.

Some teams choose to do this once per Sprint, while others may do shorter, but more frequent, refinement sessions. We can debate the merits of estimation, or the level of detailed planning needed by the team, but you can’t argue the value of collaborative discovery, where the team learns, explores, designs and estimates together.

Are your teams actively collaborating, or just sitting in a room with one person talking, while everyone else wishes they were somewhere else?

Conclusion

If you see this activity being ignored, or you sense that your team is struggling to plan and/or deliver consistently because of this, bring the topic into your next Retrospective, identify the impediment and commit, as a team, to overcome that obstacle.  Although I advocate having the entire team involved, the absence of a few team members should not prohibit the rest of us from having the conversation. Be practical, show up prepared and use your time wisely.

High-performing teams are the ones that learn together, deliver together and succeed (as well as fail) together.  Give Backlog Refinement the respect it deserves and your Scrum team, particularly the value and quality of what they produce, will definitely improve.

 

iJeff Sutherland, Ken Schwaber 2013 http://www.scrumguides.org/ iihttp://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Scrum horrorscopes for sprint 7, 2015

/by

It is with sadness that we have followed the discussions on predictability in software development, as well as the raging Twitter debates on #NoEstimates. On one hand, Scrum practitioners are much aware of the difficulties inherent in estimating and predicting, but on the other hand we are all drawn towards the perceived certainty in a well-defined plan.

However, since software development is a complex-responsive system, it is clear to any thinking and knowledgeable individual that changes in the constellations will for sure affect the events happening to a Scrum team*. The experienced coaches and trainers from agile42 have gazed into their crystal balls (and in the case of Niels, the bowels of a grilled chicken) and drawn up the appropriate horrorscopes. Just be sure to choose the right one.

Scrummastaries

AriesYour role as supportive mentor to the rest of your team may feel uncomfortable at times, but it gives you a wonderful perspective on your workmates that no one else has. You are beginning to appreciate the hidden power of “coaching” people around. The force is with you, young Scrum Master. But you are not a coach… yet.

The immediate future does indeed look rosy and this sprint might already go better than you anticipated. However, dark clouds are spreading on the horizon as the next release draws nearer, and you must think carefully about how to make the team deliver everything on time. At the same time, stakeholders are growing more adamant in their demands for increased velocity. Look for creative synergies!

Resist the urge to straighten out the burndown, as it is unlikely that anybody will actually look at it much this sprint.

Productownrus

TaurusLife is a fluid experience, especially this upcoming sprint. Things keep changing, and usually you’re ready to roll with the punches. However, a situation you thought had been resolved rears its ugly head. The relationship with some stakeholders may become bumpy towards the end of the sprint.

In hindsight it would have been a good idea to consolidate the views of the stakeholders into one common product vision at the beginning of the project. As the damage is already done, creating one now is likely to be a waste of time.

The upcoming changes may require some painful adjustments on your part, and you are reluctant to seek help from the team. Although you may be able to talk them around in mid sprint, you might also have considered just handing them some brand new stories in the next sprint planning. Both options are open — but only one is the right choice, so pick carefully!

People may bring up the question of product quality again, so make sure to keep a symbolic reservation for bugfixing in the sprint. But only symbolic, mind you, as the stakeholders really want to see the new features you promised earlier.

Towards the end of the sprint the developers may raise this recurring question of technical debt. The situation is again very easy to resolve, as you can just defer to the stakeholder demands for more features.

Pairprogramini

GeminiEstimates you gave at beginning of the project will magically become commitments during this or next sprint. To make matters worse, the estimation jokes you threw earlier were duly noted by the Project Manager who will now divide all numbers by three.

In this sprint, you will also finally realize the full WTFness of the code base, which seems to have been designed using the “onion model”. The closer you look, the more you feel like crying.

The architecture change proposal that would restore a semblance of sanity to the product will be turned down by the System Architect when he gets around to reading it in early May. Without a version control system and proper automated tests, rewinding the code base to comply with the Architecture Description will be… interesting. Resolving the situation requires thinking outof thebox, as well as polishing your CVs.

Teamrus

TaurusThings may seem rather chaotic this sprint as you run around juggling all your projects. Don’t make any commitments now, as you can’t fully see the implications of what you might be agreeing to. In fact, don’t even make any estimates.

The company seems to employ three managers for every developer, which can be a chore sometimes. If working with others seems to require too much synchronization and diplomacy, just be frank about what you think about other people’s work. They will appreciate it later. Also fly solo whenever you see an opportunity for it.

If you have hidden resources, they may not survive this sprint. More specifically, the unlisted old desktop that serves as the development hub for the team is likely to be discovered by IT and its MAC address blocked “for security reasons”. Just lie low for about three weeks until Marketing accidentally draws the attention of IT by exceeding their disk quota, then silently change the MAC address.

Ceopricorn

CapricornYou will meet a dark stranger with a business proposal. In fact, you will most likely receive seven or eight proposals this week, all from Nigeria. Do not deign to reply unless the sum offered is at least 17 million USD.

Your quest to find the right aglee…? eagley…? uh, agile scaling method requires high levels of subtlety, diplomacy and expertise — all things that you excel at. Just invite every sales representative to the same meeting and let them duke it out. But don’t hurry to pick the winner. While you certainly need to show stockholders that you have a strategy around this ugly…? achoo…? um, agile thing, remember that your own compensation plan may eventually be at stake! Ask your best strategy analysts to form a committee and study their quarterly reports with care.

Other than that, interesting opportunities are cropping up. Your new blonde secretary went out for dinner last week but only with her sister, and she is not in fact seeing anyone at the moment. Also, a near relative who knows something about computers is going to be looking for a job in the near future, so you may want to start finding faults in one of the Vice Presidents who is currently doing something with computers.

Architarius

AquariusYou appear as if you’re open to other people’s ideas now, but chances are you have already decided your course of action. Make a point of listening, but stay firm. Don’t take too much stress if you are dragged into uncomfortable discussions. Instead of trying to emerge victorious in an argument as usual, just smile and walk away.

Despite initial misgivings, it is likely that you will win the next performance review round. Your boss is feeling strong peer pressure, but agrees with you in heart. After all, you know the product better than anybody else in the company, and cannot be held responsible when developers misunderstand things. The coupe de grace would be to get KPIs for enforcing system architecture compliance into the next round.

Piëmisces

PiscesYou have cleared many a difficult decision and quite understandably feel like hibernating for a month. But keep your eyes open, and an opportunity for diving into action will present itself! This is a fantastic time to be a Project Manager, as you have a chance to accomplish much more than you expect if you only stay focused on your goals (and the CEO on his new secretary).

If the defect situation becomes overwhelming, downprioritize some bugs. You can always up-prioritize them again later.

As to the matter of making the deadlines, hang on for as long as possible before letting everyone know that you will not deliver on time. The early estimates you demanded from the developers will come in handy now.

Your friends give you differing advice on how to extend your collection of certificates or whether, indeed, to just rest on your laurels. In the end however, a certificate on the wall is better than ten in the bush, and people with both PMI and Agile certificates seem to be in high demand. Choose wisely!

Qualibra

LibraThe product quality responsibility weighs heavily on your shoulders. During sleepless nights, you may be pondering the wisdom of taking responsibility for something you cannot actually do anything about. Discussing your concerns with a colleague is unwise, as it could serve to make you seem incompetent or weak in the eyes of the whole unit.

There is a growing risk that you will be facing an increased workload towards the end of the sprint. In fact you will be testing all stories on the last days of the sprint. In the retrospective the developers on the team will make sure to point out that unlike you, they completed most of their tasks for the sprint.

Until now, you have marshalled your strength and dug down into your work in an admirable way. But during this sprint, your feelings about the situation should begin to shift, reflecting a change in the cosmic energy. If you could somehow encourage the developers to check their own work, there might be room for real testing and the opportunity to provide stakeholders with valuable information about the product. However, your manager firmly believes that developers are not to be trusted with testing their own code, so that’s that.

Stakeo

LeoManaging a project can be like a dance: one leads while the others follow. Right now one of the stakeholders seem to be in the middle of a political tango (or possibly the Swan Lake, it’s too early to say). Your goal should be to approach this group, find synergies, align your strategies and streamline the process, but in order to do that you may have to let them lead for a while.

While you can convince others that your position is a solid one, you’re not going to persuade anyone with only words this sprint. Language is shallow and just won’t carry across your deep conviction. Beauty is currently the major motivating force, so take your time and act only when your aesthetic sense says yes. Do make sure to save every email and make notes of every phone call, in case you need to “clarify” things later.

Analystarius

SagittariusYour best allies are those who think the same way you do — people who are smart, inventive, creative, nimble and flexible! Working together you can achieve anything! With a little brainstorming, what previously seemed like a fairly big issue turns out to be entirely doable, and getting it rolling is a lot of fun.

The System Architect may try to prevent you from going forward, but will back down if you don’t take any notice. You will find a true friend in the UX designer, who appreciates the possibility of changing the color and position of the user interface elements every two weeks.

On the other hand, your relationship with the developers will cool down even further after you update the acceptance criteria of the stories the team selected for the sprint. But remember that the development teams are supposed to be agile. If this doesn’t mean the ability to adapt to change, then what does it mean?

Sceptio

ScorpioThe upcoming sprints will be a disaster, and your future looks correspondingly bright! All the meetings and overhead in the agileschmagile approach has prevented you from doing real work, and you will now have all the chances to put blame where it belongs. Before long you will be sitting in peace in your cubicle again, your tasks comfortably 90% done and only held back by a few pesky technical problems that should be resolved within a couple of days, tops.

However, one of the most important skills you still need to master is knowing when to ask for help. It’s important to not immediately call out to friends or coworkers if you feel like you’re in over your head. Only when details pile up and obscure your route to success should you start compiling a list of books to read, or think about participating in some training. The farther you can go on your own, the better! After all, you are the specialist.

Databancer

CancerYou’re tempted to exceed your role description in order to support your colleagues.

This little self-indulgence of adding a field here and optimizing a table there would normally be fine, except you’ll probably realize that such lighthearted distractions are not necessarily bringing you towards your professional goals. Besides, after they caused the database seizure last week and then tried to shift the blame on you, you are simply not in the mood to help out.

You may now be seeking ways of preventing unauthorized access to the database. However, you won’t get what you want if you push too hard. It takes a delicate touch to deploy your intentions without stirring up unnecessary resistance. Silently retract all “unnecessary” access to the database, and talk to the Product Owner to add a comprehensive administration interface to the project instead. Although you have had your differences in the past, the System Architect appreciates your method of defining each table dynamically in another table — sheer genius! — and will be happy to sign off your design.

Keep your chin up and if anyone needs anything, just pretend to be really busy with finalizing the full data structures for the upcoming project. Don’t be surprised if this makes some people uncomfortable, but stick to your guns and don’t be intimidated. After all, the database is the foundation of every nontrivial project, and they will learn to appreciate the importance of proper database administration.

 

* Because of quantum.

** Yes, there are two tauruses… taurii… tauruseses… whatever. See it as an Easter egg.

Sign images from freedesign4.me. Photo of Bracken House, London by Remko van Dokkum – http://flic.kr/p/6Ddfuu

Mile High Agile: Breaking Down Technically Complex Stories

/by

On Friday, April 3rd, I’ll get the chance to talk with other Agile practitioners at Mile High Agile 2015 about a topic I’ve been excited about for years – breaking down technically complex user stories.

The stories we’re talking about are the ones that may look easy on the surface (maybe as simple as a single button) but hide a mountain of intricacy underneath, in supporting systems, database design, or a dozen other areas that may not be visible to the end user.

To break these kinds of epic stories up, we’ll need to reestablish our understanding of what delivering valuable software means. We’ll be focusing on working software that lets us engage with our users without getting hung up on some of the stereotypes and assumptions that stand in our way.  We’ll also diving into some concrete examples with real code to see what these broken down stories look like and, we’ll examine some of the technical practices around refactoring and dependency injection that will enable our teams to incrementally deliver value in these situations.

Many people run into these stories and feel this is where Agile starts to lose consistency and has to be patched around the problem.  However, I have come to see that this is where Agile development really shines through and helps teams create great software.

Join me Friday, April 3rd at Mile High Agile 2015 and see how breaking down technically complex stories can help your team.