Skip to content

Feed aggregator

Kite on a Stick

Business Craftsmanship - Tobias Mayer - Tue, 11/18/2014 - 22:58

In this episode of The Weekenders, Tito spends the weekend trying to organize his friends to follow his agenda, with disappointing results. Frustrated, he comes home for dinner…

Tino’s Mom: You know, a kite flies on a string, not a stick.
Tino: [pause] Wow! I could see your lips moving, but it was like you were just going “blah, blah-blah”.

image
Sometimes, organizational change conversations feel like this.

.  

Categories: Blogs

Have You Signed Up for the Conscious Software Development Telesummit?

Johanna Rothman - Tue, 11/18/2014 - 20:14

Do you know about the Conscious Software Development Telesummit? Michael Smith is interviewing more than 20 experts about all aspects of software development, project management, and project portfolio management. He’s releasing the interviews in chunks, so you can  listen and not lose work time. Isn’t that smart of him?

If you haven’t signed up yet, do it now. You get access to all of the interviews, recordings, and transcripts for all the speakers. That’s the Conscious Software Development Telesummit. Because you should make conscious decisions about what to do for your software projects.

Categories: Blogs

Rally Integrates QASymphony Test Management Tool

Scrum Expert - Tue, 11/18/2014 - 20:09
QASymphony has announced a partnership with Rally Software. QASymphony’s qTest test case management tool now fully integrates with Rally’s Agile Platform for Application Lifecycle Management (ALM). This enhanced qTest integration to Rally ALM allows customers to leverage the power of exploratory, manual, and automated testing all in one easy to use platform. Additionally, customers are granted seamless traceability out of one tool and in to the other. qTest is a scalable QA software testing management platform optimized for enterprise Agile development teams. Available as a SaaS application or installed on-premise, qTest ...
Categories: Communities

VersionOne Gets $20 Million Investment

Scrum Expert - Tue, 11/18/2014 - 19:05
VersionOne has announced the completion of a $20 million investment by private equity firm LLR Partners. The strategic investment supports VersionOne’s continued product innovation and market expansion as the global adoption of agile software development accelerates. Founded in 2002, VersionOne helps companies succeed with agile development. The company’s all-in-one software solution for agile lifecycle, collaboration, quality, business intelligence, and portfolio management simplifies enterprise-scale software planning and tracking. Expert training, coaching, and consulting provides technology organizations with the skills and confidence to successfully transition to agile methods such as Scrum, Lean, Kanban, ...
Categories: Communities

Lean Startup in the Wild – Lessons From a Picky Customer

BigVisible Solutions :: An Agile Company - Tue, 11/18/2014 - 18:39

Lean Startup in the Wild Meet Scoo ( just one of her many names ). Scoo is approximately 3 years old, a lover of bags, owner of all things with string, hedonistic, energetic, a tyrant to her older siblings, and famous for her contrarian attitude. Scoo, I was to come to fully realize somewhat later, is […]

The post Lean Startup in the Wild – Lessons From a Picky Customer appeared first on BigVisible Solutions.

Categories: Companies

Tips to Start Agile in a Hostile Environment

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally.  In some cases, management may even be hostile to the concepts and practices of Agile methods.  If you are interested in Agile, you don’t have to give up hope (or look to switch jobs).  Instead, here are some tips to start using Agile methods even in hostile environments.

Regular Retrospectives

Some Agilists claim that the retrospective is actually the key to being Agile.  In some ways, this is also the easiest practice to introduce into an organization.  Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“.  These are retrospectives that can be done in 15 minutes or half an hour.  Try to do them with your team weekly.  If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting.  If you are “just” a team member, you might have to get some modest amount of permission.

So why would it be good to do a retrospective?  Because it’s a high return-on-investment activity.  For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning.   Here are a couple more articles about the importance of retrospectives:

What’s an Agile Retrospective and Why Would You Do It?

What is a Retrospective?

Practice-by-Practice

Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start.  Myself, my first formal Agile environment, I started with the Daily Scrum.  Another time less formal, I started with Test-Driven Development.  In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months.  This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders.  This is the practice-by-practice approach.  Start with a simple Agile practice that you can do without asking anyone for permission.  Make sure it is a practice that makes sense for your particular environment – it must produce some benefit!  If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start.  If you are more business-oriented, then maybe consider user stories or one of the Innovation Games.  If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.

It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another.  If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.

Stealth Project

Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy.  This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”.  This is an opportunity to do Agile.  Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.”  There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support.  In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it.  Don’t talk about it.

The “just do it” approach requires that you have some influence.  You don’t have to be an influencer, but you need connections and you need charisma and you need courage.  If you don’t have at least two of those three, you shouldn’t try this approach.  You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works.  Here are a few comments on Stealth Methodology Adoption.

Co-Conspirators

There’s nothing like working with a band of rebels!  If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work.  Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans.  Of course, you need to actually execute some of your plans.  Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.

But, like any rebellion, you really need to trust those you work with in these early stages.  Lacking that trust will slow everything you do possibly to the point of ineffectualness.  Trust means that you have, for some time, a formal vow of silence.  Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.

Read “Fearless Change”

I can’t recommend this one enough!  Read “Fearless Change” by Mary Lynn Manns and Linda Rising.  This is a “patterns” book.  It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use.  Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent.  Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.

Don’t Call it “Agile”

This isn’t really a “tip” in the sense of an action item.  Instead, this is a preventative measure… to prevent negative reactions to your proposals for change.  The words “Agile” or “Scrum”, while they have their supporters, also have detractors.  To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names.  Use another name.  Or let your ideas go nameless.  This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”.  By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.

A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”.  Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.

Get Some Training

Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program.  It’s a 40-week program that takes about 12 hours/week of your time for coursework.  The next cohort of participants starts in June 2015 and we are taking deposits for participants.  This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

Spice up your Agile Retrospectives

Ben Linders - Tue, 11/18/2014 - 13:10
In the mini-workshop Experience new exercises to spice up your agile retrospective #RetroValue that I gave at Lean Kanban France teams experienced three different retrospectives exercises. They learned how retrospectives can help them to gain deeper insight in their situation and came up with actions to deal with problems and improve their performance. Continue reading →
Categories: Blogs

A Coaching Experiment

Growing Agile - Tue, 11/18/2014 - 11:45

This month Karen and I were lucky enough to have 2 unplanned sessions with a group of other coaches. It was so great to talk to fellow coaches about what’s working, what isn’t, to hear their war stories, get their advise, and to share our stories. We feel we benefitted greatly from these conversations, so our monthly retrospective action was to come up with 3 ideas to connect with other coaches. Here are our thoughts.

 

IDEA #1

For a group of 3-5 coaches to sign up for a 2 month experiment. Each person will coach another person for an hour every 2 weeks. The coaches might be international – so you would need to figure out a time that suits you and the other coach.

You will get a personal coaching session every 2 weeks.

You will give (another) coach a personal coaching session every 2 weeks.

After 2 months (roughly 4 sessions) we will all reflect and see if this worked or not.

 

IDEA #2

To have a local meetup for coaches to attend. You need to be a coach to attend. Perhaps we can borrow the Lean Coffee approach for this.

 

IDEA #3

To create an online call for 3-5 coaches to attend every 2 weeks for around 90 minutes. The time will depend on the attendees – could be international. Each coach gets a turn to facilitate the group session.

We run it for 4 sessions and then reflect in the 5th how it worked.

 

For each of these ideas the attendees need to come prepared to give and to get. It will need to be a safe and trusted environment. There should be no money exchange happening. We give our services freely and expect the same from others.

Do any of these sound like a winner to you? Which would you be interested in? 

We would like to start these in mid January – so if you are keen – please drop us an email or leave a comment below. Let us know which idea you like the best – or if you have another idea!

 

Categories: Companies

Ready, Test, Go!

Xebia Blog - Tue, 11/18/2014 - 11:42

The full potential of many an agile organization is hardly ever reached. Many teams find themselves redefining user stories although they have been committed to as part of the sprint. The ‘ready phase’, meant to get user stories clear and sufficiently detailed so they can be implemented, is missed. How will each user story result in high quality features that deliver business value? The ‘Definition of Ready’ is lacking one important entry: “Automated tests are available.” Ensuring to have testable and hence automated acceptance criteria before committing to user stories in a sprint, allows you to retain focus during the sprint. We define this as: Ready, Test, Go!

Ready

Behaviour-Driven Development has proven to be a fine technique to write automated acceptance criteria. Using the Gherkin format (given, when, then), examples can be specified that need to be supported by the system once the user story is completed. When a sufficiently detailed list of examples is available, all Scrum stakeholders agree with the specification. Common understanding is achieved that when the story is implemented, we are one step closer to building the right thing.

Test

The specification itself becomes executable: at any moment in time, the gap between the desired and implemented functionality becomes visible. In other words, this automated acceptance test should be run continuously. First time, it happily fails. Next, implementation can start. This, following Test-Driven Development principles, starts with writing (also failing) unit tests. Then, development of the production code starts. When the unit tests are passing and acceptance tests for a story are passing, other user stories can be picked up; stories of which the tests happily fail. Tests thus act as a safeguard to continuously verify that the team is building the thing right. Later, the automated tests (acceptance tests and unit tests) serve as a safety net for regression testing during subsequent sprints.

Go!

That's simple: release your software to production. Ensure that other testing activities (performance tests, chain tests, etc) are as much as possible automated and performed as part of the sprint.

The (Agile) Test Automation Engineer

In order to facilitate or boost this way of working, the role of the test automation engineer is key. The test automation engineer is defining the test architecture and facilitating the necessary infrastructure needed to run tests often and fast. He is interacting with developers to co-develop fixtures, to understand how the production code is built, and to decide upon the structure and granularity of the test code.

Apart from their valuable and unique analytical skills, relevant testers grow their technical skills. If it cannot be automated, it cannot be checked, so one might question whether the user story is ready to be committed to in a sprint. The test automation engineer helps the Scrum teams to identify when they are ‘ready to test’ and urges the product owner and business to specify requirements – at least for the next sprint ahead.

So: ready, test, go!!

Categories: Companies

A Manager’s Trip – from insane to sane

Scrum 4 You - Tue, 11/18/2014 - 08:30

I can’t shake off the impression that being a manager and guilt somehow goes hand in hand. It seems like managers cannot have a peace of mind for a few minutes, especially in the current online world. A manager is online 24/7, on her laptop, blackberry, smartphone. The work follows her like a shadow (which the online world basically is). But instead of embracing this digital world, managers tend to dislike it. In my opinion, the reason for that is that managers still have the illusion of a traditional work-life-balance. I have noticed that the traditional work-life-balance, in other words, 8 hour work day (Monday to Friday) does not exist.

The manager will always lose with the traditional 5 work day (38 hours/week) mindset. It seems like the manager cannot satisfy anybody, not even herself. Of course you can always work harder and much more, but the fact is not how much you work rather than how effectively you use your time. The reality is that you cannot work on three projects at the same time. You cannot persuade yourself by thinking three hours of sleep every night is fine. These habits will lead to a self-destructing life sooner or later. If you want to be effective as a manager then you have to commit yourself on one task at a time. You are asking why?

Pretty simple: sleep deprived people are not good at rational decision making nor are they awake enough for decoding the gut feeling which helps to make the right decision. (There is a reason why studies found out that a person with 24 hours sleep deprivation drives as a good as someone who is drunk). Hence, people who lack a lot of sleep are basically useless.

So what could be the solution to this problem? You could quit your job and start growing vegetables in your garden or just make a few changes to your lifestyle. For example, I have found these solutions working for me:

  1. I sleep 8 hours a day (here are 10 reasons why) and that means I am not reachable except when someone is calling my emergency number.
  2. I stopped doing several things at a time, instead I do only one task at a time – multitasking is a myth, which simply does not work (if you do not believe me look at this interview with Stanford professor Clifford Nass).
  3. As a Scrum Consultant I have learned to commit myself to the one thing at a time. In other words to my sprint planning and daily tasks, which leads to a focused and better outcome.

My main responsibility as a ScrumMaster is to enhance efficiency, and a burned-out Manager would stop the productivity completely. As a ScrumMaster you have to act as a manager, shrink, developer, doctor, engineer, etc. I call it a 360° versatile role. So this goes out to the managers who understand where I am coming from. Just try this for a month and tell me about your experiences.

Related posts:

  1. Boris moves on – Embrace change
  2. Organisations need to understand …
  3. Estimation, Estimation, Estimation

Categories: Blogs

Building A #BADA55 Node Development Environment: The Video!

Derick Bailey - new ThoughtStream - Tue, 11/18/2014 - 00:50

Over the weekend, I attended and spoke at the Nodevember conference in Nashville, TN. At this conference, I spoke on the subject of destroying your IDE in favor of using smaller, light-weight, flexible and composable tooling like Grunt, Grunt-Contrib-Watch and others. I had a strongly positive amount of feedback from the session, which is always nice, and I felt like it went well. 

Delete your ide

If you’d like to get my slides (PDF and Keynote), you can do so at my Github repository for the presentation.

GitHub.com/derickbailey/bada55-node-dev

If you weren’t there, or even if you were and you want to watch it again, the amazing crew from Nodevember ensured that all talks were recorded and made available free of charge on YouTube. You can watch the video directly on YouTube, or here in the blog post:

     Related Stories 
Categories: Blogs

Enforced Workflow is inherently NOT Agile

Agile Management Blog - VersionOne - Tue, 11/18/2014 - 00:01

balancing actOne of the ironies of being a technologist in the Agile world is that while we love our tools and toys, we also know that some things should be done by hand.  One of my jobs as a consultant at VersionOne is to help people understand what the tool will and won’t do.  Needless to say, I believe wholeheartedly that the tool does all that it should, and is a fantastic tool for understanding where we are as a team, and where we intend to go.  Its a very interesting balancing act, and I have always been impressed, especially when I was a customer, at how well the product management team performs this act.

 

I am often asked “when will you automate the workflow for a [epic/story/task/test]”?  My answer has been the same for quite some time now:  “hopefully never”.  This gets me some interesting responses, mostly disbelief.  The fact that the workflows are not predefined is not a missing feature, but a fundamental understanding of a basic fact.  Automated workflows are inherently not Agile.

Let’s start with the most glaring evidence of this statement.  The Agile Manifesto’s very Face-to-face-marketingfirst identified value is Individuals and Interactions over Processes and Tools.  Tools are valuable when they enable interactions between individuals.  When they start to replace those interactions, we are hurting ourselves.  Agile is about being able to be quick on our feet and embrace change, even late in development.  Having a tool enforce what should happen next slows that down.  Let the tool represent what is going on, not try to decide what is going on.

needless complexityThe next challenge is the fact that Agile teams understand the pitfalls of Big Design Up Front.  If  we acknowledge that trying to create an entire design and architecture up front is a waste of time and energy, why don’t we acknowledge the same for designing a process up front?  There are just too many different states that a story, etc. can be in during development to be able to predict the flow.  Any attempt to do so is taking energy away from our primary purpose, which is providing value to our customers.  Obviously we will have some agreements of general ideas, like Test comes first, and a story isn’t accepted until all of the tests pass, but we don’t need to automate that.

Lastly, let’s remember the main difference between Agile planning ideas and traditional planning ideas.  The idea around Agile processes’ planning is to reflect and react to reality.  VersionOne provides many ways to do this, my favorite being Team Rooms.  I want a wall sized monitor where I can project my Team Room on the wall in my workshop, providing me with a giant informed work-space.  Traditional processes try to bend reality to some arbitrarily decided workflow.  And guess what? Whenever there is a battle between our planned workflow and reality, reality will always win.

Categories: Companies

Agile Portfolio Management with Visual Studio 2013

TV Agile - Tue, 11/18/2014 - 00:00
With Agile Portfolio Management, organizations can manage goals and requirements that can span multiple teams and sprints. This video demonstrates the new Agile Portfolio Management features in Team Foundation Server 2013.
Categories: Blogs

Dealing With Middle Management in Scrum

Scrum Expert - Mon, 11/17/2014 - 20:52
When companies transition to Agile, it is not too difficult to find new roles for member of the current software development teams. Finding a place for middle management in the new organization is not so easy and some people even advocates to get rid of them. In this blog post, Em Campbell-Pretty brings her own middle management perspective to this discussion. She discusses the fact that middle management wouldn’t block change, but would actually be the people leading the change successfully. It will be difficult to have Agile teams if middle ...
Categories: Communities

ScrumDay Oviedo, Oviedo, Spain, December 13 2014

Scrum Expert - Mon, 11/17/2014 - 18:55
ScrumDay Oviedo is a one-day conference focused on Scrum and Agile software development that takes place in the Spanish city of Oviedo. All the presentations are in Spanish. In the agenda of ScrumDay Oviedo you can find topics like Agile adoption, team coaching, technical best practices and product ownership. Web site: http://www.scrumdayoviedo.com/ Location for the 2014 conference: Auditorio – Palacio de Congresos “Príncipe Felipe”, Plaza Gesta, 33007 Oviedo, Asturias, Spain
Categories: Communities

How To Build a Roadmap for Your Digital Business Transformation

J.D. Meier's Blog - Mon, 11/17/2014 - 17:09

Let’s say you want to take your business to the Cloud --  How do you do it?

If you’re a small shop or a startup, it might be easy to just swipe your credit card and get going.

If, on the other hand, you’re a larger business that wants to start your journey to the Cloud, with a lot of investments and people that you need to bring along, you need a roadmap.

The roadmap will help you deal with setbacks, create confidence in the path, and help ensure that you can get from point A to point B (and that you know what point B actually is.)  By building an implementable roadmap for your business transformation, you can also build a coalition of the willing to help you get their faster.  And you can design your roadmap so that your journey flows continuous business value along the way.

In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share how top leaders build better roadmaps for their digital business transformation.

Why You Need to Build a Roadmap for Your Digital Transformation

If you had infinite time and resources, maybe you could just wing it, and hope for the best.   A better approach is to have a roadmap as a baseline.  Even if your roadmap changes, at least you can share the path with others in your organization and get them on board to help make it happen.

Via Leading Digital:

“In a perfect world, your digital transformation would deliver an unmatched customer experience, enjoy the industry's most effective operations, and spawn innovative, new business models.  There are a myriad of opportunities for digital technology to improve your business and no company can entertain them all at once.  The reality of limited resources, limited attention spans, and limited capacity for change with force focused choices.  This is the aim of your roadmap.”

Find Your Entry Point

Your best starting point is a business capability that you want to exploit.

Via Leading Digital:

“Many companies have come to realize that before they can create a wholesale change within their organization, they have to find an entry point that will begin shifting the needle.  How? They start by building a roadmap that leverages existing assets and capabilities.  Burberry, for example, enjoyed a globally recognized brand and a fleet of flagship retail locations around the world.  The company started by revitalizing its brand and customer experience in stores and online.  Others, like Codelco, began with the core operational processes of their business.  Caesars Entertainment combined strong capabilities in analytics with a culture of customer service to deliver a highly personalized guest experience.  There is no single right way to start your digital transformation.  What matters is that you find the existing capability--your sweet spot--that will get your company off the starting blocks.

Once your initial focus is clear, you can start designing your transformation roadmap.  Which investments and activities are necessary to close the gap to your vision?  What is predictable, and what isn't? What is the timing and scheduling of each initiative? What are the dependencies between them?  What organizational resources, such as analytics skills, are required?”

Engage Practitioners Early in the Design

If you involve others in your roadmap, you get their buy-in, and they will help you with your business transformation.

Via Leading Digital:

“Designing your roadmap will require input from a broad set of stakeholders.  Rather than limit the discussion to the top team, engage the operational specialists who bring an on-the-ground perspective.  This will minimize the traditional vision-to-execution gap.  You can crowd-source the design.  Or, you can use facilitated workshops, as as 'digital days,' as an effective way to capture and distill the priorities and information you will need to consider.  We've seen several Digital Masters do both.

Make no mistake; designing your roadmap will take time, effort, and multiple iterations.  But you will find it a valuable exercise.  it forces agreement on priorities and helps align senior management and the people tasked to execute the program.  Your roadmap will become more than just a document.  If executed well, it can be the canvas of the transformation itself.  Because your roadmap is a living document, it will evolve as your implementation progresses.”

Design for Business Outcome, Not Technology

When you create your roadmap, focus on the business outcomes.   Think in terms of adding incremental business capabilities.   Don’t make it a big bang thing.   Instead, start small, but iterate on building business capabilities that take advantage of Cloud, Mobile, Social, and Big Data technologies.

Via Leading Digital:

“Technology for its own sake is a common trap.  Don't build your roadmap as a series of technology projects.  Technology is only part of the story in digital transformation and often the least challenging one.  For example, the major hurdles for Enterprise 2.0 platforms are not technical.  Deploying the platform is relatively straightforward, and today's solutions are mature.  The challenge lies in changing user behavior--encouraging adoption and sustaining engagement in the activities the platform is meant to enable.

Express your transformation roadmap in terms of business outcomes.  For example, 'Establish a 360-degree understanding of our customers.'  Build into your roadmap the many facets of organizational change that your transformation will require customer experiences, operational processes, employee ways of working, organization, culture, communication--the list goes on.  This is why contributions from a wide variety is so critical.”

There are lots of way to build a roadmap, but the best thing you can do is put something down on paper so that you can share the path with other people and start getting feedback and buy-in.

You’ll be surprised but when you show business and IT leaders a roadmap, it helps turn strategy into execution and make things real in people’s minds.

You Might Also Like

10 High-Value Activities in the Enterprise

Cloud Changes the Game from Deployment to Adoption

Drive Business Transformation by Reenvisioning Operations

Drive Business Transformation by Reenvisioning Your Customer Experience

Dual-Speed IT Drives Business Transformation and Improves IT-Business Relationships

How To Build a Better Business Case for Digital Initiatives

How To Improve the IT-Business Relationship

How Leaders are Building Digital Skills

Management Innovation is at the Top of the Innovation Stack

Categories: Blogs

A Tech Lead Paradox: Consistency vs Improvement

thekua.com@work - Mon, 11/17/2014 - 13:32

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Consistency versus Improvement.

The case for consistency

Code is easier to understand, maintain and modify when it is consistent. It is so important, that there is a wiki page on the topic and the 1999 classic programming book, The Pragmatic Programmer: From Journeyman to Master had a chapter titled, “The Evils of Duplication.” Martin Fowler wrote about similar code smells, calling them “Divergent Change” and “Shotgun Surgery” in his Refactoring book.

Consistency ultimately helps other developers (or even your future-self) change code with less mental burden figuring out of there will be unwanted side-effects.

The case for improvement

Many developers want to use the latest and greatest tool, framework or programming language. Some examples: Java instead of C/C++, Python/Ruby instead of Java, JavaScript (Node) instead of Python/Ruby and then Clojure in place of JavaScript. The newest and latest technologies promise increased productivity, fewer bugs and more effective software development. Something that we all want. They promise the ability to accomplish something with fewer lines of code, or a simpler, clearer way to write something.

The conflict

Software is meant to be soft. Software is meant to be changed. A successful codebase will evolve over time, but the more features and changes a codebase has, the harder it becomes to add something new without making the codebase inconsistent. When a new technology is added to the mix, there is suddenly two ways of accomplishing the same thing. Multiple this over time and number of transitions, and a codebase suddenly has eight different ways of accomplishing

Transitioning everything to a new technology is a function takes time. Making a change to an old part of the system is a gamble. Leaving the codebase as it is makes potentially new change in this area hard. That new change may never happen. Migrating everything over has the risk of introducing unwanted side-effects and taking time that may never be worth it.

To the developer wanting the new technology, the change appears easy. To those who have to follow up with change (i.e. other team members or future team members) it may not be so clear. Making it consistent takes time away from developing functionality. Business stakeholders want (understandably) justification.

Phil Calçado (@pcalcado) tweeted about this paradox:
As a dev, I love going for the shiny language. As a manager, I want a mature ecosystem and heaps of bibliography on how to write decent apps

What does a Tech Lead do?

Tech Leads ride the paradox by encouraging improvement and continually seeking consistency. But how? Below I provide you with a number of possible solutions.

Use Spike Solutions

Spikes are a time-boxed XP activity to provide an answer to a simple question. Tech Leads can encourage spike solutions to explore whether or not a new technology provides the foreseeable benefit.

Improvement spikes are usually written stand-alone – either in a branch or on a separate codebase. They are written with the goal of learning something as fast as possible, without worrying about writing maintainable code. When the spike is over, the spike solution should be thrown away.

Spikes provide many benefits over discussion because a prototype better demonstrates the benefits and problems given a particular codebase and problem domain. The spike solution provides a cheap way to experiment before committing to a particular direction.

Build a shared roadmap

Improvements are easy to make to a small, young codebase. Everything is easily refactored to design a new tool/technology. It’s the larger longer-lived codebases that are more difficult to change because more has been built up on the foundations that must be changed.

A Tech Lead establishes a shared understanding with the team of what “good” looks like. Specifically, which tool/technology should be used for new changes. They keep track of older instances, looking to transition them across where possible (and where it makes sense).

Techniques like the Mikado Method are indispensable for tackling problems that eating away at the bigger problem.

Playback the history

A new developer sees five different ways of doing the same thing. What do they do? A Tech Lead pre-empts this problem by recounting the story of how change was introduced, what was tried when and what the current preferred way of doing things are.

Ideally the Tech Lead avoids having five different ways of accomplishing the same thing, but when not possible, they provide a clear way ahead.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

Make Implicit Concepts Explicit in Code

Dear Junior
In our letters on software development we have touched upon the idea several times, but I think it might be worth spelling it out - the idea to make implicit concepts explicit; something I see as one central message of Domain Driven Design applied to coding.

Let me pick that phrase apart for a moment. When coding we have a lot of concepts in mind, e g when writing code that handles people I might have a class namned Person. In this case the concept of person has an explicit representation in the code - i e an explicit concept.

A person might have a birth date, represented in code as a data-field Date dayofbirth in the Person class; another example of an explicit concept.

We might have business logic restrictions that are based on the age of the person, e g you have to be at least fifteen years to access some content. So there will be code calculating this.

    void contentRequest() {
        ... 
        boolean access = ((new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear) >= 15;

Again we have a concept represented in code, this time age. However, this time the representation is not explicit - there is nothing in the code saying "age". Age is an implicit concept

There is nothing strange with having implicit concepts. In the short code snippet we have several implicit concepts: current point of time, point of time of customer's birth, and age-limit for content are just three obvious. This is not a problem. The programmer reading the code will intuitively re-construct the relevant concepts.

However, the design guideline from Domain Driven Design advice us to keep an eye open for important concepts - and if we find the represented implicitly, then make that implicit concept explicit

Let us look at the code snippet again.

        boolean access = ((new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear) >= 15;

Of the implicit concepts dwelling in this like, which of them seem important enough to make explicit? 

The concept of "current point of time"? Probably not.

The concept of "milliseconds since birth"? Nah, not that either.

The concept of "milliseconds since birth expressed as years, rounded downwards"? Hey! I know this! We already have a word for it - we call it "age"! And we talk about it all the time!

Well, that sounds important enough. Let us start with giving that value a name. 

    void contentRequest() {
        ... 
        long age = (new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear;        boolean access = age >= 15;
By the way: this is where I really like the IntelliJ shortcuts "cmd-w" to widen the selection until the expression is selected, then "cmd-alt-v" for the refactoring to extract the selection as a variable - naming it "age" in the pop-up. It literally takes less than 10 seconds.

Now, we actually have made the implicit concept age into an explicit concept. Mission completed.

Well, not completely. We need to find the concept a good home where it can lead a good life. Right now it is stranded in the middle of some access computation. At least we can give it a method of its own.

Applying another of my favourite refactoring "Replace Temp with Query" yields this code.

    void contentRequest() {
        ... 
        boolean access = customerAge(customer) >= 15;

    private long customerAge(Person customer) {        return (new Date().getTime() - customer.dayofbirth.getTime()) / msPerYear;    }
Better, but can be improved to make the concept clearer. If we talk about the "age of the customer" it will vary from time to time, and it might cause confusion: the age when the customer requested access to the content, the age when content was first accessed, when it was last accessed, the age now? Better to clarify.
Of course we could rename the method to "customerAgeNow". However, I do not feel comfortable having my concepts depend implicitly on external things like the system clock. I prefer to make those dependencies explicit. So we make the time-in-question a parameter. 
    void contentRequest() {        ... 
        boolean access = customerAgeAt(customer, new Date()) >= 15;
    private long customerAgeAt(Person customer, Date timepoint) {        return (timepoint.getTime() - customer.dayofbirth.getTime()) / msPerYear;    } This design also improves testability drastically. The tests can now use explicit test-data, and need not rely on checking, or changing, the system clock.
Kudos once again to the lovely refactoring support of modern IDEs. Another less-than-10-seconds-refactoring: two cmd-W to select "new Date()", cmd-alt-P to extract as parameter, change name to "timepoint" in pop-up. Enter. Done.
By now it is pretty obvious that the method "customerAgeAt" suffers from feature envy. The most relevant data it operates upon is the Customer, but it resides somewhere else. We should consider moving it.
Should we move it, the Customer class would get a method "ageAt", taking the liberty to rename it slightly. That method certainly makes sense in this context, but does it so in other contexts? As we do  not have the rest of the codebase at hand, we will just have to pretend that "ageAt" makes sense in other context - and might actually be useful there as well.
This is really one of my favourite refactoring: move method. Again extremely smooth thanks to modern IDEs. Literally two keystrokes (F6, Enter - in IntelliJ) for the move, and a few for renaming. 
    void contentRequest() {        // ...        boolean access = customer.ageAt(new Date()) >= 15;
class Person {
    Date dayofbirth;
    // ...
    long ageAt(Date timepoint) {
        return (timepoint.getTime() - dayofbirth.getTime()) / TimeUtil.msPerYear;
    }
}

You might not believe me, but I remember the days of yore when you actually had to do all the involved steps manually; cut-n-paste the method body and header, change the list of parameters, update the code to use the fields of "this" instead of the argument, change all client calls (which might be several).

Now, we have finally ended up with a version I feel comfortable with. The concept "person" has now an conceptual attribute "age at" which has an explicit representation in code. In code we have "enhanced" our language of what we can talk about directly. So, when we discuss the age of a customer with business people, it is likely that we consistently mean the same thing - even if we for sure still can misunderstand each other.

As a side effect the code checking the access has become a lot clearer.

        boolean access = customer.ageAt(new Date()) >= 15;

This is a line of code that can be shown some person from the business side and explained by reading it out "access is granted if the customer's age at 'now' is at least fifteen years". Given that support, they can see by themselves - something that really builds trust. 
The time invested was not huge. Coding-wise all refactorings took less then a minute together. The time to slowly realise that "age" is an important concept in this particular domain is not counted. However, that insight will have to dawn on the programmer sooner or later, and when that happens, that extra minute is well invested.
To make concepts explicit does not only apply to code, it can be fruitfully applied to other areas as well, e g capturing and writing requirements/specifications. 
As we all stand on shoulders of gigants, I also must give credit where credit is due. The phrase "Make Implicit Concepts Explicit" I have picked up from Eric Evans, the thought leader of Domain Driven Design. 
In conclusion: to make implicit concepts explicit help us to over time close the gap between the code and the understanding of the business domain. It is not uncommon to in the process find bugs or crucial misunderstandings, that then can be adressed in a proactive manner instead of popping up as nasty surprises later on. 

Yours 

   Dan





Categories: Blogs

The value of focus training

Henrik Kniberg's blog - Mon, 11/17/2014 - 12:50

Strangely, in most companies people are considered perfectly healthy until they suddenly burn out. While in reality, it seems that a large number of people are somewhere between those two states, and could use some help to get more focused and less stressed.

We had a guy, Mattis Erngren, visit us at Crisp and do a session on focus training and meditation. Very pragmatic, interesting, and useful session. Highly recommended. Mattis and his company Lightly are on a mission to make focus training a standard offering at all companies, just like other health benifits like gym and such things. The brain is a muscle and it needs training too, to stay in shape.

So go ahead and contact the guys at http://lightly.io and bring them over. They offer free trial sessions so it’s really a no-brainer.

Incidentally, Jeff Sutherland was at the session at Crisp, and revealed that he used to be an avid meditator, and that Scrum was actually conceived during a meditation session. As in, the idea behind Scrum popped into his head right after a session. Interesting! When you clear your mind from all the noise, you make room for the really powerful stuff.

Categories: Blogs

Photo

Business Craftsmanship - Tobias Mayer - Mon, 11/17/2014 - 09:08


Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.