Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Developers: We're spending money, consuming resources, producing outputs that the customer likes.¬†
Project Manager: I was more interested in what's our performance against¬†our planned spend, planned resource consumption, and planned outputs of value to the customer?¬†
Developers:¬†What do you mean, we didn't estimate any of that, we're managing this project with #NoEstimates. You know that new alternative to estimates for making decisions in software development. That is ways to make decisions with "No Estimates." of the impacts on the future of those estimates or of our work on the future cost, schedule, or technical performance. You know where we can use¬†Decision making frameworks for projects that do not require estimates, or apply¬†Investment models for software projects that do not require estimates, and have our project management methods for risk management, scope management, progress reporting, not require any of those annoying estimates. 'Cause we kinda suck at them anyway, so we just decided instead of learning how to estimate, we'll just not estimate and get back to coding.
Project Manager:¬†Oh, you mean that approach of managing other peoples money that violates the principles of software microeconomics with Open Loop Control - where¬†our organization can make business decisions on the allocation of our limited resources, without examining how those decisions effect the supply and demand of our resources. You do know about those resources? Like money, people, and time?
Developers: Yea, we don't need any that mumbo jumbo microeconomics that we all learned in school, since we didn't pay attention in that boring the statistics and probability class that tried to teach us that all variables on a project are actually random variables and we should to know something about their behaviour in the future if we're going have a hope in hell of ever managing this project in the presence of uncertainty about those values.
Project Manager: What's that smell?¬†Maybe we'd better start rearranging the deck chairs on our ship here real soon, cause I smell an Iceberg getting closer.
No project can be managed to successful closure in the absence of steering targets defined at periodic intervals for the expenditure of cost, schedule, and technical performance. Knowing what those steering targets should be requires estimating their values, then measures the actual values to develop the needed steering signal - the variance between plan and actual.
The only way out of the need to estimate those intermediate steering targets is to¬†straight line the budget, schedule, and needed technical performance - from start to end, then measure the actual performance.¬†
Like the intended route of the Titanic, our project does not proceed in a straight line, so that idea is a non-starter. And like the Titanic, our project cannot confuse the intended speed with the actual speed, just like we can't confuse the budget - the total planned crossing time - with the actual cost - the actual total crossing time.
Without those pesky intermediate targets to steer toward - those targets created by estimating the¬†needed cost, needed scheduled arrival date, and, needed capabilities on the needed date¬†for the needed cost. We're managing the project Open Loop, driving in a straight line. Never knowing what will pop up in front of our path.¬†
Say good bye to Kate Leonardo, you're gonna get wet.
‚Ä† Full attribution for the inspiration for this post comes from the very useful blog by Gene HughsonRelated articles Staying on Plan Means Closed Loop Control How Not To Make Decisions Using Bad Estimates Control Systems - Their Misuse and Abuse More Than Target Needed To Steer Toward Project Success Why Project Management is a Control System
In our first post we busted the myth that cloud != high performance and outlined the steps to 1 Million TPS (100% reads in RAM) on 1 Amazon EC2 instance for just $1.68/hr. In this post we evaluate the performance of 4 Amazon instances when running a 4 node Aerospike cluster in RAM with 5 different read/write workloads and show that the r3.2xlarge instance delivers the best price/performance.
Several reports have already documented the performance of distributed NoSQL databases on virtual and bare metal cloud infrastructures:
I am a Xamarin fanboy, so my excitement about Xamarin.Forms is perhaps unsurprising. But I see an awful lot of potential for this technology. I want to show you some of the stuff we've been doing with Xamarin.Forms here at Zumero.Andrew Jackson in Two Minutes
First I am going to race through this demo very quickly. Then I'll circle back around and explain things.STEP ONE: Download ZAG and run it
Visit http://zumero.com/dev-center/zss/#zag and download the ZAG application. For this demo, I'm using ZAG on Mac OS X (but you could choose Windows or Linux) and I am targetting iOS (but you could choose Android or Windows Phone).
When you run the app, you should see something like this:
STEP TWO: New Database
Under the "File" menu, choose "New Database...". You should see this dialog:
Fill in the Server URL and DBFile exactly as shown in the screen shot (Server URL: "http://demo.zumero.com:8080". DBFile: "demo"). Click the OK button. You should see a dialog asking you where to save the local copy of the database:
Click OK. You should see "Syncing with the ZSS Server":
And when the sync is complete, at the bottom of the ZAG window, you should see "Sync result: 0 (success)".STEP THREE: Generate
Under the "Generate" menu, find and choose the item labeled "Xamarin.Forms C#":
You will be asked three questions, and you should be able to just click OK on all three.STEP FOUR: Open the sln file
You can quit the ZAG application now. It should have generated a folder somewhere like /Users/eric/Documents/demo.zssdemo/. Under that folder you should find a Xamarin solution tree that looks something like this:
Double-click the demo.sln file to open it in Xamarin Studio. You should see four C# projects: a Portable Class Library called "demo.Shared", plus one app target each for iOS, Android, and Windows Phone 8:
STEP FIVE: Build and run the app
If you build and run the demo.iOS app in the iPhone simulator, you should see something like this:
STEP SIX: Sync
Click the "Sync" button in the upper right. You should see:
The defaults should be fine. Just tap the "Sync Now" button. When the sync is completed, you should see a list of tables:
STEP SEVEN: Andrew Jackson
Tap the "presidents" table. In an iPad instance of the simulator, you would see this:
And tap the seventh item. You should see Andrew Jackson, the only U.S. president ever to kill someone in a duel:
What is ZAG?
ZAG is short for "ZSS App Generator". It's a desktop app which generates ready-to-build source code and build scripts for mobile apps that sync using ZSS.
We think of ZAG as a way for getting people started faster. Many people come to our product without much experience in mobile app development. ZAG can be used to give them a starting point, sort of like sample code that is customized for their data.What is Zumero for SQL Server?
Zumero for SQL Server (ZSS) is a solution for data sync between SQL Server and mobile devices.
More info from Dan Bricklin about offline in mobile apps: http://bricklin.com/offline.htm
More info about Zumero on our website: zumero.com
More info about Zumero from my previous blog entry: hereWhat is demo.zumero.com:8080?
This is a publicly accessible ZSS server provided so that folks can play with Zumero clients more easily. It contains some basic sample data such as U.S. presidents and the periodic table of the elements.
In real-world scenarios, a customer would use ZAG to generate their starter app after they have completed setup of their ZSS server.What is Xamarin?
Xamarin is (IMHO) a great solution for building mobile apps.
One of the main benefits of the Xamarin platform is the ability to write the non-UI parts of your iOS/Android/WP8 apps in cross-platform code while implementing a native user interface for each mobile environment.
But I would use Xamarin even for a single-platform app, simply to get the benefits of working in .NET/C#.
More info on the Xamarin website: http://xamarin.com/What is Xamarin.Forms?
Xamarin.Forms is Xamarin's solution for making [most of] your UI code cross-platform as well, while retaining fully native performance and feel.
In a nutshell, the coolness of Xamarin.Forms lies in the fact that in the solution generated by ZAG above, the demo.Shared project is a Portable Class Library even though it contains the entire user interface for the app.
More info on the Xamarin website: http://xamarin.com/formsWhat is a Portable Class Library (PCL)?
A PCL is a .NET class library that is annotated with information about which platforms it should support. This metadata allows the tooling to enforce portability rules in both the development and the consumption of the library.
More info on Scott Hanselman's blog: http://www.hanselman.com/blog/CrossPlatformPortableClassLibrariesWithNETAreHappening.aspx
More info on the Xamarin website: http://developer.xamarin.com/guides/cross-platform/application_fundamentals/pcl/introduction_to_portable_class_libraries/Why does ZAG generate separate projects for iOS, Android, and WinPhone?
Xamarin.Forms can make most of your UI code portable, but not all of it. The actual building of the mobile app is specific to each platform. But if you look in the code for each of those platform-specific projects, you'll see that there isn't much there.What dependencies does the ZAG-generated app have?
The following NuGet packages will need to be retrieved:
This is the Portable Class Library (PCL) version of SQLite-net, the popular lightweight SQLite ORM by Frank Krueger (@praeclarum).
More info on GitHub: https://github.com/praeclarum/sqlite-net
More info on the NuGet website: https://www.nuget.org/packages/sqlite-net-pcl/What is the "SQLitePCL.raw_basic" NuGet package?
SQLitePCL.raw is my Portable Class Library for accessing SQLite from C#.
More info on Github: https://github.com/ericsink/SQLitePCL.raw
More info on the NuGet website: https://www.nuget.org/packages/SQLitePCL.raw_basic/What is SQLite?
SQLite is the most popular SQLite database for mobile devices.
More info on the SQLite website: sqlite.orgWhat is the "Zumero" NuGet package?
This is the Zumero Client SDK in the form of a Portable Class Library in a NuGet package.
More info on the Zumero website: http://zumero.com/dev-center/zss/
More info on the NuGet website: https://www.nuget.org/packages/Zumero/What do Zumero's client-side SQLite files look like?
As much as possible, they look exactly like they looked in SQL Server.
Table and column names are the same.
All data values are the same (whenever possible).
Foreign keys in SQL Server are reconstructed as foreign keys in SQLite.
Since SQLite does not perform type checking, Zumero adds constraints to do so.
And so on...What's happening in step two?
ZAG is acting as a Zumero client and synchronizing the data on the server into a local SQLite file. This file is used to obtain information about the tables and columns necessary to generate the mobile app.
The same sync is happening in step six, except then it is the mobile app performing the sync instead of ZAG.What were those three questions in step three?
The first one is the project name:
Then ZAG wants to know the settings for your sync server. These should already be filled in with the ones you entered earlier:
Finally, ZAG is asking you where to save the source code and project files for the app to be generated:
Does a ZAG-generated app allow modifications to the data?
For the Xamarin.Forms C# target, yes. On the item detail page, you should be able to enter new values in text fields and 'Save' the changes.
But you should get a permission denied error if you try to sync those changes to our public demo server. :-)Is ZAG generating UI stuff as XAML or as C# code?
Currently, it's XAML. You'll find the files in the 'xaml' folder in the demo.Shared project.Does ZAG generate polished ready-to-use apps?
Oh definitely not. :-)
The output of ZAG should build and run with no errors (if it doesn't, it's a bug, and please let us know), but it's just a starting point for further development.
Deciding on which software size metric you should use is a fairly momentous decision. Much like deciding on a development platform the decision on which size measure will commit an organization to different types of tools, process and techniques. For example the processes and tools needed to count lines of code would be different than those needed to support story points as a sizing technique. The goals of the measurement program will be instrumental in the determining which type of size metrics will be the most useful. Measurement goals will help you choose between¬†four macro attributes¬†of¬†organization specific and industry defined metrics and between physical and logical metrics. For example, if benchmarking against other firms or industry data is required to attain your measurement goal using organizationally defined metrics would be less viable. Similarly if you have a heterogeneous software environment then selecting a functional metric would make more sense than using a physical metric (logical metrics normalizes varied technology).
Figure 1:Balancing Organizational Perspective Versus Organizational Environment
The second checkbox is whether the measure has an externally defined and documented methodology. Why is definition important? Definition is the precursor to repeatability and consistency, which allows comparability. Consistency and repeatability are prerequisites for the ability to generate data needed to use the scientific method such as Six Sigma and tools used to support Kiazen. Finally, an external definition reduces the amount of effort that is required to construct and implement measurement programs.
Even where a definition exists a wide range of nuances are possible. Examples of the range of definitions begin with the most defined, the functional precision of ISO functional metrics to the less defined methodology of Use Case Points which began with a single academic definition and has evolved into many functional variants. The variants seen in UCP are a reflection of having no central control point to control methods evolution, which we will explore later in this model. The range of formality of definition is captured in Figure¬†2.
Figure¬†3¬†consolidates the view of formality of definition with the delineation between logical and physical metrics. Each measure has strengths and weaknesses. The first two items in our checklist are macro filters.
Each measure of size fits a specific combination of organizational goals, environmental constraints and needs however the field of potential software sizing metrics is wide and varied. Once the macro filter is applied each subsequent step in the checklist will narrow the field of potential size measures.
‚ÄúYour work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do.‚ÄĚ ‚ÄĒSteve Jobs
What does it take to create a company where everybody gives their best where they have their best to give?
It takes empathy.
It also takes encouraging people to be zestful, zany, and zealous.
It takes bridging the gap between the traits that make people come alive, and the traits that traditional management practices value.
In the book The Future of Management, Gary Hamel walks through what it takes to create a company where everyone gives their best so that employees thrive and companies create sustainable competitive advantage.Resilience and Creativity: The Traits that Differentiate Human Beings from Other Species
Resilience and creativity are what separate us from the pack.
‚ÄúAsk your colleagues to describe the distinguishing characteristics of your company, and few are likely to mention adaptability and inventiveness. Yet if you ask them to make a list of the traits that differentiate human beings from other species, resilience and creativity will be near the top of the list. We see evidence of these qualities every day -- in ourselves and in those around us. ‚ÄúWe Work for Organizations that Aren't Very Human
People are adaptive and creative, but they often work for organizations that are not.
‚ÄúAll of us know folks who've switched careers in search of new challenges or a more balanced life. We know people who've changed their consumption habits for the sake of the planet. We have friends and relatives who've undergone a spiritual transformation, or risen to the demands of parenthood, or overcome tragedy. Every day we meet people who write blogs, experiment with new recipes, mix up dance tunes, or customize their cars. As human beings, we are amazingly adaptable and creative, yet most of us work for companies that are not. In other words, we work for organizations that aren't very human.‚ÄĚModern Organizations Deplete Natural Resilience and Creativity
Why do so many organizations underperform? They ignore or devalue the capabilities that make us human.
‚ÄúThere seems to be something in modern organizations that depletes the natural resilience and creativity of human beings, something that literally leaches these qualities out of employees during daylight hours. The culprit? Management principles and processes that foster discipline, punctuality, economy, rationality, and order, yet place little value on artistry, nonconformity, originality, audacity, and √©lan. To put it simply, most companies are only fractionally human because they make room for only a fraction of the qualities and capabilities that make us human. Billions of people show up for work every day, but way too many of them are sleepwalking. The result: organizations that systematically underperform their potential.‚ÄĚAdaptability and Innovation Have Become the Keys to Competitive Success
There‚Äôs a great big gap between what makes people great and the management systems that get in the way.
‚ÄúWeirdly, many of those who labor in the corporate world--from lowly admins to high powered CEOs--seem resigned to this state of affairs. They seem unperturbed by the confounding contrast between the essential nature of human beings and the essential nature of the organization in which they work. In years past, it might have been possible to ignore this incongruity, but no longer--not in a world where adaptability and innovation have become the sine qua non of competitive success. The challenge: to reinvent our management systems so they inspire human beings to bring all of their capabilities to work every day.‚ÄĚThe Human Capabilities that Contribute to Competitive Success
Hamel offers his take on what the relative contribution of human capabilities that contribute to value creation, recognizing that we now live in a world where efficiency and discipline are table stakes.
Passion 35% Creativity 25% Initiative 20% Intellect 15% Diligence 5% Obedience 0% 100%
‚ÄúThe human capabilities that contribute to competitive success can be arrayed in a hierarchy. At the bottom is obedience--an ability to take direction and follow rules. This is the baseline. Next up the ladder is diligence. Diligent employees are accountable. They don't take shortcuts. They are conscientious and well-organized. Knowledge and intellect are on the next step. Most companies work hard to hire intellectually gifted employees. They value smart people who are eager to improve their skills and willing to borrow best practices from others. Beyond intellect lies initiative. People with initiative don't wait to be asked and don't wait to be told. They seek out new challenges and are always searching for new ways to add value. Higher still lies the gift of creativity. Creative people are inquisitive and irrepressible. They're not afraid of saying stupid things. They start a lot of conversations with, 'Wouldn't it be cool if ..." And finally, at the top lies passion.‚ÄĚ
The Power of Passion
Passion makes us do dumb things. But it‚Äôs also the key to doing great things.
Via Via The Future of Management:
‚ÄúPassion can make people do stupid things, but it's the secret sauce that turns intent into accomplishment. People with passion climb over obstacles and refuse to give up. Passion is contagious and turns one-person crusades into mass movements. As the English novelist E.M. Forster put it, 'One person with passion is better than forty people merely interested.'‚ÄĚObedience is Worth Zip in Terms of Competitive Advantage
Rule-following employees won‚Äôt help you change the world.
‚ÄúI'm not suggesting that obedience is literally worth nothing. A company where no one followed any rules would soon descend into anarchy. Instead, I'm arguing that rule-following employees are worth zip in terms of their competitive advantage they generate. In a world with 4 billion nearly distributed souls, all eager to climb the ladder of economic progress, it's not hard to find billable, hardworking employees. And what about intelligence? For years we've been told we're living in the knowledge economy; but as knowledge itself becomes commoditized, it will lose much of its power to create competitive advantage.‚ÄĚObedience, Diligence, and Expertise Can Be Bought for Next to Nothing
You can easily buy obedience, diligence, and expertise from around the world.
But that‚Äôs not what will make you the next great company or the next great thing or a great place to work.
‚ÄúToday, obedience, diligence, and expertise can be bought for next to nothing. From Bangalore to Guangzhou, they have become global commodities. A simple example: turn over your iPod, and you'll find six words engraved on the back that foretell the future of competition: 'Designed in California. Made in China.' Despite the equal billing, the remarkable success of Apple's music business owes relatively little to the company's network of Asian subcontractors. It is a credit instead to the imagination of Apple's designers, marketers, and lawyers. Obviously not every iconic product is going to be designed in California, not nor manufactured in China. ‚ÄúYou Need Employees that are Zestful, Zany, and Zealous
If you want to bring out the best in people and what they are capable of, aim for zestful, zany, and zealous.
‚ÄúThe point, though, is this: if you want to capture the economic high ground in the creative economy, you need employees who are more than acquiescent, attentive, and astute--they must also be zestful, zany, and zealous.‚ÄĚ
If you want to bring out your best, then break our your zest and get your zane on.You Might Also Like
So Agile 2014 is over again‚Ä¶ and what an interesting conference it was.
What did I find most rewarding? Meeting so many agile people! My first conclusion was that there were experts like us agile consultants or starting agile coaches, ScrumMasters and other people getting acquainted with our cool agile world. Another trend I noticed was the scaled agile movement. Everybody seems to be involved in that somehow. Some more successful than others; some more true to agile than others.
What I missed this year was the movement of scrum or agile outside IT although my talk about scrum for marketing had a lot of positive responses. ¬†Everybody I talked to was interested in hearing more information about it.
There was a talk maybe even two about hardware agile but I did not found a lot of buzz around it. Maybe next year? I do feel that there is potential here. I believe Fullstack product development should be the future. Marketing and IT teams? Hardware and software teams? ¬†Splitting these still sounds as design and developer teams to me.
But what a great conference it was. I met a lot of awesome people. Some just entering the agile world; some authors of books I had read which got me further in the agile movement. I talked to the guys from Spotify. The company which is unique in its agile adoption / maturity. And they don‚Äôt even think that they are there yet. But then again will somebody ever truly BE agile ..?
I met the guys from scrum.inc who developed a great new scaled framework. Awesome ideas on that subject and awesome potential to treat it as a community created open framework; keep your eyes open for that!
I attended some nice talks too; also some horrible ones. Or actually 1, which should never have been presented in a 90 minute slot in a conference like this. But lets get back to the nice stories. Lyssa Adkins had a ‚Äėtalk‚Äô about conflicts. Fun thing was that she actually facilitated the debate about scaled agile on stage. The session could have been better but the idea and potential of the subject is great.
Best session? Well probably the spotify guys. Still the greatest story out there of an agile company. The key take-out of that session for me is: agile is not an end-state, but a journey. And if you take it as serious as Spotify you might be able to make the working world a lot better. Looking at Xebia we might not even be considered to be trying agile compared to them. And that is meant in a humble way while looking up to these guys! - I know we are one of the frontiers of agile in the Netherlands. The greatest question in this session: ‚ÄėWhere is the PMO in your model‚Ä¶.‚Äô
Well you clearly understand this ‚Ä¶
Another inspiring session was the keynote session from the CFO of Statoil about beyond budgeting. This was a good story which should become bigger in the near future as this is one of the main questions I get when implementing agile in a company: ‚Äúhow do we plan / estimate and budget projects when we go and do agile?‚ÄĚ Beyond budgeting at least get‚Äôs us a little closer.
Long story short. I had a blast in Orlando. I learnt new things and met a lot of cool people.My main take out: Our community is growing which teaches us that we are not yet there by a long run. An awesome future is ahead! See you next year!
If any of these items interest you there's a full description of each sponsor below. Please click to read more...
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
In last month’s newsletter I wrote about how we make personal financial decisions in a now vs. not-now manner. We don’t map out must-haves, should-haves, could-haves, and won’t haves. And I promised in this month’s newsletter, I would cover a simple approach to now vs. not-now planning while still accommodating working toward a bigger vision for a product.
I always recommend having a medium-term vision for where a product is headed. I find a three-month horizon works well. At the start of each quarter, a product owner should put a stake in the ground saying “Here’s where we want to be in three months.” This is done in conjunction with the team and other stakeholders, but the ultimate vision for a product is up to the product owner.
A product owner doesn’t need to be overly committed to the vision—it can be changed. But, without a stake in the ground a few months out, prioritization decisions are likely to be driven by whatever emergencies erupt right before sprint planning meetings. Without a vision, the urgent always wins over the strategic.
For choosing between competing ideas for a medium-term vision, I like using a formal approach—that is, something I can explain to someone else. I want to be able to say, “I chose to focus on such-and-such rather than this-and-that” and then show some analysis indicating how I made that decision. I’ve written elsewhere about relative weighting, theme screening and theme scoring—and we have tools on this website for performing those analyses.
But at the start of each sprint, a product owner needs to make the smaller now vs. not-now decisions of prioritizing user stories to be worked on in the next one sprint. Rather than using a formal, explainable approach for that, I advise product owners consider four things about the product backlog items they are evaluating:
I do this by first sorting the candidate product backlog items on attribute one, the value of each feature. There’s nothing special about this; it’s how product people have prioritized features for years.
But I don’t stop there. I use items two through four to adjust the now sorted backlog. For the most part, I will move product backlog items up rather than down based on the influence of these additional factors. Let me explain what each factor is about.
The second factor refers to how much learning will occur by developing the feature. Learning can take many forms—for example, a team might learn about the technology being used (“this vendor’s library isn’t as easy as we were told it would be”) or a product owner might learn how well users respond to a new user interface. If the learning that will result from developing a particular product backlog item is significant, I will move that item up the product backlog so it is developed in the coming sprint.pro
As for riskiness, if a given risk cannot be avoided, I prefer doing that product backlog item sooner rather than later so that I can learn the impact of the risk. And so, I will move the product backlog item up into the current sprint. If, however, there is a chance of avoiding a risk entirely (perhaps by not doing the feature at all), I will move that product backlog item out of the current sprint. I’ll then hopefully continue to do that in each subsequent sprint, thereby avoiding that risk entirely.
Finally, some features can be cheap if they are done now or expensive if they are put off. When I see such an item on a product backlog, I will move it into the current sprint to avoid the higher cost of delaying the feature.
By combining the use of these four factors when selecting items for a sprint with a formal approach to establishing a medium-term, three-month vision, you’ll be able to successfully prioritize in a now vs. not-now manner within the context of achieving a bigger goal.
For one of my projects we wanted to create some nice charts. Feels like something you often want but do not do because it takes to much time. This time we really needed it. We had a look at D3.js library, a very nice library but so many options and a lot to do yourself. Than we found c3.js, check the blog post by Roberto: Creating charts with C3.js. Since I do a lot with AngularJS, I wanted to integrate these c3.js charts with AngularJS. I already wrote a piece about the integration. Now I went one step further by creating a set of AngularJS directives.
You can read the blog on the trifork blog:
The term¬†Systems Thinking is many times used in vague and unspecified ways to mean¬†think about the system and all will emerge in a way needed to produce value.¬†
Systems Thinking¬†is a term toosed around many times with little regard for what it actually means and its relationship to¬†Systems Engineering and¬†Engineered Systems.
But systems thinking is much more than that.¬†Systems thinking provides a rigorous way of integrating¬†people, purpose, process and performance and: ‚Ä†
‚Ä† ¬†"How Systems Thinking Contributes to Systems Engineering," INCOSEUK, Z7, Issue 1.0, March 2010.Related articles A Breathtaking Paper Positive Deviance
Frameworks to choose the best projects in organizations are a dime a dozen.
In every organization there will a preference for one of these or similar methods to choose where to invest people‚Äôs precious time and money.
Are all these frameworks good? No, but they aren‚Äôt bad either. They all have some potential positive impact, at least when it comes to reflection. They help executive teams reflect on where they want to take their organizations, and how each potential project will help (or hinder) those objectives.
So far, so good.‚ÄúEverybody‚Äôs got a plan, until they get punched in the face‚ÄĚ ~Tyson Surviving wrong decisions made with perfect data
However, reality is seldom as structured and predictable as the plans make it out to be. Despite the obvious value that the frameworks above have for decision making, they can‚Äôt be perfect because they lack one crucial aspect of reality: feedback.Models lack on critical property of reality: feedback.
As soon as we start executing a particular project, we have chosen a path and have made allocation of people‚Äôs time and money. That, in turn, sets in motion a series of other decisions: we may hire some people, we may subcontract part of the project, etc.
All of these subsequent decisions will have even further impacts as the projects go on, and they may lead to even more decisions being made. Each of these decisions will also have an impact on the outcome of the chosen projects, as well as on other sub-decisions for each project. Perhaps the simplest example being the conflicts that arise from certain tasks for different projects having to be executed by the same people (shared skills or knowledge).
And at this point we have to ask: even assuming that we had perfect data when we chose the project based on one of the frameworks above, how do we make sure that we are still working on the most important and valuable projects for our organization?Independently from the decisions made in the past, how do we ensure we are working on the most important work today? The feedback bytes back
This illustrates one of the most common problems with decision making frameworks: their static nature. They are about making decisions "now", not "continuously". Decision making frameworks are great at the time when you need to make a decision, but once the wheels are in motion, you will need to adapt. You will need to understand and harness the feedback of your decisions and change what is needed to make sure you are still focusing on the most valuable work for your organization.All decision frameworks have one critical shortcoming: they are static by design. How do we improve decision making after the fact?
First, we must understand that any work that is ‚Äúin flight‚ÄĚ (aka in progress) in IT projects has a value of zero, i.e., in IT projects no work has value until it is in use by someone, somewhere. And at that point it has both value (the benefit) and cost (how much we spend maintaining that functionality).
This dynamic means that even if you have chosen the right project to start with, you have to make sure that you can stop any project, at any time. Otherwise you will have committed to invest more time and more money (by making irreversible ‚Äúbig bang‚ÄĚ decisions) into projects that may prove to be much less valuable than you expected when you started them. This phenomenon of continuing to invest beyond the project benefit/cost trade-off point is known as Sunk Cost Fallacy and is a very common problem in software organizations: because reversing a decision made using a trustworthy process is very difficult, both practically (stop project = loose all value) and due to bureaucracy (how do we prove that the decision to stop is better than the decision to start the project?)Can we treat the Sunk Cost Fallacy syndrome?
While using the decision frameworks listed above (or others), don‚Äôt forget that the most important decision you can make is to keep your options open in a way that allows you to stop work on projects that prove less valuable than expected, and to invest more in projects that prove more valuable than expected.
In my own practice this is one of the reasons why I focus on one of the #NoEstimates rules: Always know what is the most valuable thing to work on, and work only on that.
So my suggestion is: even when you score projects and make decisions on those scores, always keep in mind that you may be wrong. So, invest in small increments into the projects you believe are valuable, but be ready to reassess and stop investing if those projects prove less valuable than other projects that will become relevant later on.
The #NoEstimates approach I use allows me to do this at three levels:
Do you want to know more about adaptive decision frameworks? Woody Zuill and myself will be hosting a workshop in Helsinki to present our #NoEstimates ideas and to discuss decision making frameworks for software projects that build on our #NoEstimates work.
If you manage software organizations and projects, there will be other interesting workshops for you in the same days. For example, the #MobProgramming workshop where Woody Zuill shows you how he has been able to help his teams significantly improve their well-being and performance. #MobProgramming may well be a breakthrough in Agile management.
Picture credit: John Hammink, follow him on twitter
All jokes aside, size matters. Size matters because at least intellectually we all recognize that there is a relationship between the size of product and the effort required to build. We might argue over degree of the relationship or whether there¬†are other attributes required to define the relationship, but the point is that size and effort are related. Size is important for estimating project effort, cost and duration. Size also provides us with a platform for topics as varied as scope management (defining scope creep and churn) to benchmarking. In a nutshell, size matters both as an input into the planning and controlling development processes and as a denomination to enable comparison between projects.
Finding the specific measure of software size for your organization is part art and part science. The selection of your size measure must deliver the data need to meet the measurement goal and to fit within the corporate culture (culture includes both people and the methodologies the organization uses). A framework for evaluation would include the following categories:
Cloud infrastructure services like Amazon EC2 have proven their worth with wild success. The ease of scaling up resources, spinning them up as and when needed and paying by unit of time has unleashed developer creativity, but virtualized environments are not widely considered as the place to run high performance applications and databases.
Cloud providers however have come a long way in their offerings and need a second review of their performance capabilities. After showing 1 Million TPS on Aerospike on bare metal servers, we decided to investigate cloud performance and in the process, bust the myth that cloud != high performance.
We examined a variety of Amazon instances and just discovered the recipe for processing 1 Million TPS in RAM on 1 Aerospike server on a single C3.8xlarge instance - for just $1.68/hr !!!
According to internetlivestats.com, there are 7.5k new tweets per second, 45k google searches per second and 2.3 Million emails sent per second. What would you build if you could process 1 Million database transactions per second for just $1.68/hr?
On any given day my inbox is full of emails from software developers asking me for advice on all kinds of topics. Even though many of these questions are unique, I‚Äôve found that many of the emails have one root, all-encompassing solution: taking action. Most people never actually do anything with their lives. Most people […]
Three types of activities are keeping you busy:
Type 1: Bad
These are the things you should not be doing. They are wasting your time but still you do them. Stop it!
In the absence of a control system that provides feedback to the progress to plan, the project is just wandering around looking for what¬†Done looks like. The notion of emergent requirements is fine. The notion of emergent¬†capabilities is not.
If we don't know what capabilities are needed to fulfill the business plan or fulfill the mission need, then we're on a¬†Death March project. We don't know what value is being produced, when we will be done, or how much this will cost when we're done.
This is the role of the project control system. Without a control system there is no way to use feedback to¬†steer the project toward success.
Control systems from Glen Alleman So when we hear we can make decisions wihout estimating the impact of those decisions on the furture outcomes of the project, we'll know to call BS. First not knowing this impact on the decision making process violates the principle of Microeconomics and second there is no way to close the loop to generate a variance signal needed to¬†steer the project to success. Related articles Staying on Plan Means Closed Loop Control Concept of Operations First, then Capabilities, then Requirements Delivering Needed Capabilities What Do We Mean When We Say "Agile Community?" More Than Target Needed To Steer Toward Project Success Getting to done!