I’ve been thinking lately about the ways that different authors explain OOP. I’ve drawn a little diagram that I would like to share with you.

The sources for this are, in no particular order:

• Eric Evans, DDD Reference
• Ivar Jacobson, Object-Oriented Software Engineering
• Peter Coad, Archetypes, Color, and the Domain-Neutral Component
• Rebecca Wirfs-Brock, Characterizing Classes
• Steve Freeman, Nat Pryce, Growing Object-Oriented Software
• Vaughn Vernon, Implementing DDD

Each of these authors has a perspective I find useful. I would love it if there was a comprehensive, single model, but so far I can’t see how to systematize them.

It gets weirder when you start collecting design principles… I might do a mind map of those some day. Somehow I can see how SOLID and GRASP (for instance) are compatible. They are pointing in the same general direction, but from different angles.

I've organized a series of interviews with 11 pragmatic experts on the topic of "individuals and interactions". We'll drill down into what this means in

The Agile Software Engineer is responsible for the design, development, and implementation of services (process and technology) required to deliver business

The Agile Software Engineer is responsible for the design, development, and implementation of services (process and technology) required to deliver business value. You are skilled in problem solving and fearless in exploring both new and innovative technologies as well as weeding through large l ...

  Continuing with the 100 Things You Must Know to Be Effective In Software Development.   I really appreciate the 2-3 new people who commented on the day 0 blog and joined our group. It got me to write today's entry on the flight home from the Scrum Gathering - something I almost certainly wouldn't have done otherwise.  So keep reading and getting friends to join - it helps.   I've been wanting...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Presenting to Agile Carolinas: Tuesday, May 21, 2013 from 6:00 PM to 8:00 PM (EDT) CPCC Overcash Center, Room 340, 1201 Elizabeth Ave Charlotte, NC 28204 Space

Recently I have been asked by several customer organizations to help them to understand how to account for the expense of agile software development. In particular, incremental delivery of solutions into production or the marketplace seem to be causing confusion with the financial people within these organizations. The details of accounting rules vary between countries, but the fundamentals are common.  In order to get properly account for the costs incurred by software development teams you need to keep track of the amount of work performed and the type of work performed to develop a given solution. Time tracking doesn't have to be complex: at one customer developers spend less than five minutes a week capturing such information.

 

Why is Time Tracking Potentially Valuable?

There are several financial issues to be aware of:

• Capitalization. For public companies capital expenses (CapEx) can potentially boost book value through the increase in assets (in this case a software-based solution) and increase in net income (due to lower operating expenses that year). On the other hand, operational expenses (OpEx) are accounted for in the year that they occur and thereby reduce net income which in turn reduces your organization's taxes for that year.
• Matching. One of the goals of good accounting is to accurately reflect the net income of the enterprise and to prevent income manipulation or "smoothing". As such a key tenet is the principle of matching revenues with the appropriate expenses. For software this means that we expense the cost of the software over the lifetime of the asset against the income at that time. An implication of this is that capitalizing software development, when appropriate, before the software goes into production clearly violates the matching principle since there is no benefit of the asset until such time.
• Tax Credits.  In some countries you can even get tax credits for forms of software development that are research and development (R&D) in nature.

The point is that the way that a software developer's work is accounted for can have a non-trivial impact upon your organization's financial position.

 

What Do Agilists Think of Time Tracking?

So, I thought I'd run a simple test. Last week on LinkedIn's Agile and Lean Software Development group I ran a poll to see what people thought about time tracking. The poll provided five options (a limitation of LinkedIn Polls) to choose from:

• Yes, this is a valuable activity (33% of responses)
• Yes, this is a waste of time (39% of responses)
• No, but we're thinking about doing so (2% of responses)
• No, we've never considered this (18% of responses)
• I don't understand what you're asking (5% of responses, one of which was mine so that I could test the poll)

The poll results reveal that we have a long way to go. Of the people inputting their time more of them believed it was a waste of time than understood it to be a valuable activity. When you stop and think about it, the investment of five minutes a week to track your time could potentially save or even earn your organization many hundreds of dollars. Looking at it from a dollar per minute point of view, it could be the highest value activity that a developer performs in a given week.

The discussion that ensued regarding the poll was truly interesting. Although there were several positive postings, and several neutral ones, many more were negative when it came to time tracking. Some comments that stood out for me included:

• It's a colossal waste of time unless you're billing a customer by the hour.
• We record time spent on new development work (as distinct from other tasks such as bug fixing in legacy code and so on) as this is capitalised as an asset and depreciated.
• I think the *most* pointless example was where the managers told us what we should be putting in.
• One day we will move past the "just do it" mentality and have some meaningful conversations and the reasons for what we do.
• In my experience time tracking is a massive waste... of time. It's a poor substitute for management.
• Why do you need to know more than the info available through Sprint Backlog, Sprint burndown and the daily standup?
• Some of my teams (I am SM for three teams) are skeptical about this. They do not think that keeping track of task hours this way will be any more useful than the daily standup reports. And they do not believe that Management can resist the temptation to use task hours as a measure.

I think that there are several interesting implications from this discussion:

1. Agilists need to become more enterprise aware. It's clear to be really effective that agile delivery teams need a better understanding of the bigger picture, including mundane things such as tax implications of what they're doing.  In Disciplined Agile Delivery (DAD) this is something that we refer to as being enterprise aware.  There's far more to enterprise awareness than understanding pertinent accounting principles, for interest disciplined agile teams work towards a common technology roadmap and common business roadmap, but appreciating why time tracking is a potentially valuable activity would be a good start.
2. Management needs to communicate better.  It's also clear that management needs to communicate more effectively regarding why they're asking people to track their time. To be fair, management themselves might not be aware of the tax implications themselves so may not be making effective use of the time data they're asking for.
3. Management needs to govern more effectively. Several people were clearly concerned about how management was going to use the time data (by definition they are measures) which could be a symptom of both poor communication as well as poor governance (unfortunately many developers have experiences where measures have been used against them, a failure of governance, and no longer trust their management teams to do the right thing as a result).
4. Time tracking should be streamlined.  It was obvious from the conversation that several people worked in organizations where the time tracking effort had gotten completely out of hand.  Spending 5 minutes a week is ok, and to be quite blunt should be more than sufficient, but spending fifteen minutes or more a day doing so is far too much.  Over the years I've helped organizations design measurement programs and I've seen a lot of well-intention efforts become incredibly onerous and expensive for the people they were inflicted upon.  I suspect it's time for a reality check in some of these organizations people were alluding to.  A good heuristic is that for any measurement you should be able to indicate the real cost of collecting it, the use(s) that the information is being put to, and the value resulting from those uses.  If you can't quickly and coherently do that then you need to take a hard look at why you continue to collect that metric.  The lament "we might need it one day" is a symptom that you're wasting time and money.
5. Agile rhetoric is getting in the way.  Some of the team-focused agile practices, such as burndown charts (or better yet ranged burndown charts) and stand up meetings may be preventing people from becoming enterprise aware because they believe that all of their management needs are being met by them.
6. You may be missing out on the benefits of time tracking.  Many organizations are potentially leaving money on the table by not being aware of the implications of how to expense software development.

 

Parting Thoughts

Disciplined agilists are enterprise aware. This is important for two reasons: First, you want to optimize your organizational whole instead of sub-optimize on project-related efforts; second, you can completely miss opportunities to add real value for your organization. In the anecdote I provided it was clear that many agile developers believe that an activity such as time tracking is a waste when that clearly doesn't have to be the case. Worse yet, although someone brought up the issues around capitalizing software development expenses early in the conversation a group of very smart and very experienced people still missed this easy opportunity to see how they could add value to their organization.

Granted, time tracking on an agile project team is nowhere near as sexy as topics such as continuous integration (CI), TDD, the definition of done, continous architecture, or many more.  But you know what?  Although it's a mind-numbingly mundane issue it is still an important one. 'Nuff said (I hope).

Does your ticket sidebar look like an endless groceries list? Are you looking for a way to organize stories and epics? Are you knocking your head trying to find your way through a sea of tickets?  Then, I think you will be more than relieved to hear that we’ve released Tags for Tickets.

So, go to any ticket view and start tagging. It’s easy. Just click on the edit icon and enter a new tag or select from the existing list.

If you want to change which tags appear on the popup for users to select go to Tickets->Settings->Tag. Select Active if you want a tag to appear in the popup selector or else Hidden if you want to remove them from it.

We hope you enjoy this feature and start tagging right away! Let us if you have any comments or suggestions.

If you want to learn more about Assembla's Ticket and Issue Management System you can read more about it here.

Mingle Team First Place: Hourglass Scrum-Ban Board (Winner of an iPad Mini)

Thumbnail: 

read more

Jade Meskill, Roy van de Water, Derek Neighbors and Clayton Lengel-Zigich discuss:

• When Facilities won’t help
• When Developers can’t set up their environments
• When continuous deploy doesn’t work for marketing

Welcome to the roundup of blog posts and pages that mentioned Sonar last month…

Serie of article about Sonar installation
By Jean-Pierre Fayolle, 7 April 2013
Jean-Pierre Fayolle continues his series of articles about Sonar installation with 5 new articles:
Install Sonar – The Sonar webap
Install Sonar – Sonar Runner
Install Sonar – First analysis with Sonar Runner
Install Sonar – Jenkins
Install Sonar – The Sonar Jenkins plugin

I’ve had a love-hate relationship with two-phased commits during my years with messaging. Even if MSDTC was free to set up, it doesn’t come free in terms of throughput. Most people run into 2PC in messaging because because queueing systems and databases are two different resources, and therefore don’t participate in the same transaction. Ideally, I’d have all three participants either succeed or fail together:

Since the queues in this picture are different resources than the database, I need to involve a third party, or transaction manager, to coordinate transactions between these three resources.

DTC, when it works, works really well. It’s much, much easier to not care about the consequences of a lack of coordination. In fact, I’d recommend not caring until you actually do care, because ditching two-phased commits does require work. Luckily for us, there are a ton of resources on how to do exactly that!

Most of the time, literature around avoiding 2PC is concerned about an entirely different situation, where I have two separate databases:

We’re doing messaging, which means that it’s typically the consumer of the message that does something against other data stores. So even though we’re avoiding communicating with two databases, it’s still two resources, and thus a need to coordinate!

But again, that coordination comes with a cost. A fairly large cost, in some recent testing we found that overall throughput dropped 80%, or to put it another way, ditching DTC saw a 5X increase in throughput. Five fold!

For some systems, that throughput doesn’t matter much, but for those that have a reasonably high volume of messages, or sensitive SLAs, it’s worth investigating alternative approaches.

General rules of thumb

Like most messaging approaches, the ways of avoiding coordination are right in front of our faces. In Gregor Hohpe’s excellent paper on Starbucks, he points out any real-world system that values throughput over absolute consistency avoids distributed transactions. The basic ideas are:

• Idempotency is king. Get this and you’re halfway home
• Strategies for dealing with downstream effects is a business decision

Idempotency is absolutely required, but it’s not that hard to apply. For some operations, we can rely on natural idempotency. If I’m asked to turn on the light, receiving the request twice means the same outcome – the light is on! For state machine-like systems, idempotency is a bit easier.

For operations that aren’t naturally idempotent (launch the nuclear missile), we’ll need to get a little creative. If we can identify some correlating information from a request (The president called at 9:15 to launch the missile) or just assign some correlation information (The president has issued request #132 to launch the missile), we can simply keep a journal on the receiving side. If it’s expensive to keep a journal around, we can recycle/trim our journals if they get too big.

Downstream effects become more interesting. If throughput is a high concern, we can rely on compensating actions (customer didn’t have enough money, cancel the order) or more journaling. Instead of sending a message immediately, shouting out messages to downstream systems, we can instead just write down in the same persistent store as our other data another journal for outgoing messages.

Once our local DB transaction is complete, it’s just a matter of sending the messages we’ve written down to send out down the line, and crossing them off our list of “sent” messages. And since downstream systems can deal with at-least-once messages through our idempotency guarantees.

How I learned to stop worrying and ditch 2PC

In some current systems, we’re deciding on a service-by-service basis whether or not we want to enlist or not enlist in distributed transactions. It’s still annoying to try and build a system-wide solution (though the event sourcing guys have this more or less in the bag), so until then, I can just use business decisions to guide me one way or the other.

But it is time to let go and stop worrying so much. Honestly, unless your services have downstream side effects, you can safely turn off DTC if your work is idempotent. If you have downstream side effects, there’s a number of paths to choose from. While I’m not saying goodbye forever (still the best solution if it were absolutely free to use), it is time to shop around.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Ben Butler-Cole

The newly launched Mingle SaaS offering runs entirely on the AWS cloud. As discussed in our earlier blog on Layering the Cloud, because there is no existing system that we have to modify or integrate with, we've got the freedom to design the architecture from scratch. This has led us to rethink the role of environments in our development and deployment process.

Thumbnail: 

read more

In one of my AYE sessions, we started by completing a sentence:

Read this aloud. Feel it. Is this the way you’d like to work?

© Esther for esther derby associates, inc., 2013. | Permalink | 4 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

I need some technical help!  Someone has incompetently hijacked my Mum's PC and I'm not sure how to fix it and prevent it happening again.

---

I've spent most of this evening using logmein trying to de-hack my Mum's computer.

It looks like the daughter of the guy who does her PC support installed a remote desktop program on her laptop when he had it in his home-office setting it up for her.

My Mum said weird things were happening on it and I just thought it was her - she's 70, newish to computers, and ... well .. you know. But then weird things started happening: running out of broadband bandwidth while she was on holiday, her bookmarks disappearing and being replaced with others, strange names in browser dropdown boxes.

When one of the names in the dropdown had the same surname as her PC support guy, she figured it out.

She called her support guy and he took it away but it's still happening: I just found stuff in her history that definitely isn't my Mums.  I have their email (from looking in the Chrome browser history) for instance.

I found a chrome app installed called thinrdp and uninstalled it from chrome.  I also removed Chrome's Remote Desktop and changed the logmein passcode.  I'm worried that's not enough.

---

So this is (understandably) freaking out my Mum.  

And, I'm flummoxed: how could I have prevented this?  how can I be sure I've fixed it?  

I'm stuck .. any hints?

Hey everyone… I’m out in Vegas this week at the Scrum Gathering. Got invited to speak… which was really cool (thanks Daniel Gullo)… and did the most recent iteration of my Agile Program and Portfolio Management deck. Take a look and let me know what you think!

The post Scrum Gathering Las Vegas – Large Scale Program and Portfolio Management with Scrum appeared first on LeadingAgile.

In the past, Assembla search did not work very well. It did not match the search query to the type of searching that people were doing for a specific, recent item.  When you’re using Assembla Search the odds are you are looking for a specific document, ticket, wiki or merge request and not for a wide range of information on a certain topic. Hence, how you query and what results are relevant differ from one case to the other.

To fix this issue, we introduced a series of changes that will hopefully make your life easier when using Assembla Search. Instead of having exact and non exact match mixed in the same list of results, now you can switch between one or the other. Just type your query with quotes to look for the exact match or use the “exact match” checkbox.

We’ve also changed default sort criteria to be by date so that more recent results appear on the top of the result list (don’t worry you can still choose by relevance if you need to). To make the UI cleaner, we’ve  unified some result categories. Merge requests and Commit comments will now appear under the same tag “Merge requests”. As well, Tickets and Ticket comments results will appear under the tag “Tickets”.

We hope that with these changes you will use search more. I am using it a LOT more.  If you have any suggestions or feedback, you can post a comment here.

Need help? Learn more about How Assembla Can Help You.

There are a lot of benefits with having the testers in the Scrum teams working side by side with the developers, and not in a separate test team. However, there are also some negative aspects that can endanger the quality of the work the testers are doing. E.g. by taking part in the design work [...]

Beautiful.

In a new digital economy and a world of ultra-competition, it’s great to shape a smart organization.

We learned this long ago.   Agile was part of the early Microsoft patterns & practices DNA.   We embraced agile methods and agile management practices.

We learned that execution is king, and that shipping early and often gives you better feedback and a way to make changes in a customer-connected way.

Here is what Gartner says …

“Accepting higher project failure rates can help organizations become more efficient more quickly, according to Gartner, Inc. Gartner said project and portfolio management (PPM) leaders who take a "fail-forward-fast" approach that accepts project failure rates of 20 to 28 percent as the norm will help their organizations become more agile by embracing experimentation and enabling the declaration of success or failure earlier in a project's life.”

Check out the article, Gartner Says Smart Organizations Will Embrace Fast and Frequent Project Failure in Their Quest for Agility.

I love riding 100 mph on twisty, turning race tracks -- my favorite is Laguna Seca in Monterey, California. In racing, as in business, keeping the finish line in mind is important, but if you can’t negotiate the curves and respond quickly to changing conditions along the way -- you won’t win.

In this uber-competitive technology marketplace, the pace of change is only increasing. Disruptive new technologies are changing the game. Savvy business leaders are applying key agile concepts of continuous innovation, shorter iterations, and fail early/fail fast/fail often experiments not only to the development team - but to the entire portfolio management process.

Agile is not just for developers anymore. Once considered an esoteric “thing” that software developers “did,” Agile practices have moved mainstream and are spreading across the the enterprise. Business leaders are working to engage more people throughout the entire company to make more informed decisions at a faster pace.  The demand for better business agility is especially evident for portfolio management and strategic planning that has traditionally been tied to annual planning cycles.

An Agile business will establish a much faster cadence than the traditional annual planning cycle.  It doesn’t start and stop each quarter or once per year.  Planning and preparation become a continuous flow process with a regular cadence of weekly, monthly, and quarterly events for planning, execution, and strategic decision making.

No Time to Wait: Embrace the MVP

Betting on a big-bang project to deliver new software in a 12-to-24 month development cycle is a potential recipe for failure given the current pace of change.  Even if you are trying to plan a six-month product cycle, you may miss the latest handsets and the latest tablets - in other words, you are going to be behind.

An Agile business focuses on delivering incremental value in shorter time frames.  This means each increment has to be smaller and hyper-focused on the value to the business or customer. Desired capabilities need to be reduced to Minimal Viable Features that are validated for the scenarios people want and use.  By delivering functional software sooner, you have more opportunities to get customer feedback, adjust and adapt.

In some scenarios, evidence will suggest making small adjustments - other times a major pivot may be called for. Instead of betting the whole pot up front (as in waterfall), break opportunities into incremental objectives that can be validated along the way. By embracing the concept of a Minimum Viable Product, you can get to market quickly, then refine and expand.

Visibility and feedback are critical for steering effectively and making smart decisions.  Kanban boards help people collaborate by making it easy to see the stage of planning or development key projects are in.  Simply getting executives involved to see how much work is “in flight” on a Kanban board often brings an “ah ha” about what really matters to the business. Then, everyone can agree on working on the most important things first.

Don’t Be Left Behind

A new wave of Agile transformation is changing the way businesses fund and develop projects. Business must learn to embrace agility as more than a development approach if they are to survive. Strategic planning, product and portfolio management are now recognizing that Agile offers the best chance to keep pace and win the race. Agile is becoming a necessity for businesses trying to keep current in this changing marketplace.

To learn more about how to build an Agile business, sign up for Rally’s conference, RallyON June 3-5, 2013 and attend my session on Monster Portfolios.

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Bruce Winegarden