Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

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!

Feed aggregator

A Seat At The Table

Herding Cats - Glen Alleman - Fri, 01/10/2014 - 19:09

In a conversation on Twitter with Sridhar, there was mention that product development software projects are different than internal IT projects. And that how they are run is much different as well. This may be the case. It's not been the case in my experience in Enterprise IT for those internal projects. My experience in product development (FileNet, Triconex, Kontron) and software intensive program delivery for government, defense, space, and energy clients is that projects are expected to show up on or before the planned date, at or below the planned cost and with the agreed set of minimal capabilities to accomplish the business goals or fulfill the needed mission.

When internal IT projects lose their ability to show up on time, on budget, with the needed capabilities - all within the probabilistically defined bounds of those measures - then they lose their seat at the table. Internal IT becomes a cost. Sometimes a sunk cost. An expense. A necessary expense, but an expense all the same. And when you're only an expense, those making decisions tend to treat you differently. You have no tangible way to show your worth. In business worth is defined by revenue or cost savings. In both cases worth is defined in units of money. When you have only cash outflow you're likely not to be in the conversation about how to run the business.

There are endless books, articles, and academic papers on the topic of getting a seat at the table. Successfully delivering internal IT in support of the business. Keeping your seat the table on that business requires very specific behaviours, starting with three simple questions:

  • How much will this cost?
  • When will you be done?
  • Will it work at needed when you're done?

But the bigger question - the killer question is what are we building and why are we building it? Ignoring for the moment the problem of showing up late and over budget dilutes any value produced by the project, some times to ZERO, we must have a notion of what DONE looks like in units of measure meaningful to the decision makers. Those paying the bills for the project.

Below is a briefing of how to answer these governance questions about what and why. With that in hand the how much, when, and working are straight forward. 

Using balanced scorecard to build a project focused org2 from Glen Alleman Here are two books that have informed my journany on the path to providing value through the management of Enterprise IT projects.

There are many books on Balanced Scorecard. Some I find best are:

At The End of the Day

If you can't say, with some degree of confidence, how much you plan to spend, over what period of time, to deliver some tangible value to those paying for your work, you're not in the room when those paying for the work ae deciding what they want you to do. You're considered an expense - possibly a valuable expense. 

Categories: Project Management

Stuff The Internet Says On Scalability For January 10th, 2014

Hey, it's HighScalability time:

Run pneumatic tubes alongside optical fiber cables and we unite the digital and material worlds.
  • 1 billion: searches on DuckDuckGo in 2013
  • Quotable Quotes: 
    • pg: We [Hacker News] currently get just over 200k uniques and just under 2m page views on weekdays (less on weekends). 
      • rtm: New server: one Xeon E5-2690 chip, 2.9 GHz, 8 cores total, 32 GB RAM.
    • Kyle Vanhemert: The graph shows the site’s [Reddit] beginnings in the primordial muck of porn and programming.
    • Drake Baer: But it's not about knowing the most people possible. Instead of being about size, a successful network is about shape.
    • @computionist: Basically when you cache early to scale you've admitted you have no idea what you're doing.
    • Norvig's Law: Any technology that surpasses 50% penetration will never double again.  
    • mbell: Keep in mind that a single modern physical server that is decently configured (12-16 cores, 128GB of ram) is the processing equivalent of about 16 EC2 m1.large instances.
    • @dakami: Learned databases because grep|wc -l got slow. Now I find out that's pretty much map/reduce.
    • Martin Thompson: I think "Futures" are a poor substitute for being pure event driven and using state machines. Futures make failure cases very ugly very quickly and they are really just methadone for trying to wean programmers off synchronous designs :-) 
    • @wattersjames: Can your PaaS automate Google Compute Engine? If it can, you will find that it can create VMs in only 35 seconds, at most any scale.
    • Peter M. Hoffmann: Considering the inherent drive of matter to form ever more complex structures, life seems inevitable.

  • The marker for a new generation, like kids who will never know a card catalogue, Kodak film, pay phones, phone books, VHS tapes, typewriters, or floppy disks: Co-Founder Of Snapchat Admits He's Never Owned A Physical Server

  • Want the secret of becoming a hugely popular site? Make it fast and it will become popular. It's science. Are Popular Websites Faster?: No matter what distribution of websites you look at – the more popular websites trend faster. Even the slowest popular website is much faster than those that are less popular. On the web, the top 500 sites are nearly 1s faster (by the median), and on mobile it is closer to 1.5s faster. 

  • In 1956 we may not have had BigData, but BigStorage was definitely in. Amazing picture of IBM's 5 mega-byte drive weighing in at more than 2,000 pounds.

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge...

Categories: Architecture

No Ingrese Su Tarjeta

NOOP.NL - Jurgen Appelo - Fri, 01/10/2014 - 15:41
No Ingrese Su Tarjeta

The happiness of people doesn’t necessarily lead to improvement of their work.

The post No Ingrese Su Tarjeta appeared first on NOOP.NL.

Categories: Project Management

Systems Thinking: Difficulties

Boundaries, like fences are one potential difficulty.

Boundaries, like fences are one potential difficulty.

Systems thinking is a powerful concept that can generate significant for value for organizations by generating more options which Dan and Chip Heath indicate is a precursor to better decisions in their book Decisive. Given the power of the concept and the value it can deliver, one would expect the concept to be used more. The problem is that systems thinking is not always straightforward.  The difficulties with using systems thinking fall in to three categories.

  • Boundaries
  • Complexity
  • Day-to-Day Pressures

Organizational boundaries and their impact of the flow of both work and information have been a source of discussion and academic study for years.  Boundaries are a key tool for defining teams and providing a send of belonging, however some boundaries not very porous. As noted in our articles on cognitive biases, groups tend to develop numerous psychological tools to identify and protect their members.  Systems, in most cases, cut across those organizational boundaries. In order to effectively develop an understanding of a system and then to affect a change to that system, members of each organizational unit that touches the system need to be involved (involvement can range from simple awareness to active process changes). When changes are limited due to span of control or a failure to see the big picture, they can be focused on parts of a process that even if perfectly optimized will not translate to the delivery of increased business value.  In a recent interview for SPaMcast, author Michael West provided examples of a large telecommunication company that implemented a drive to six sigma quality in its handsets only to find out that pursuing the goal made the handset too expensive to succeed in the market. In this case the silos between IT, manufacturing and marketing allowed a change initiative to succeed (sort of) while harming the overall organization.

The second category is complexity.  Even simple systems are complex. Complexity can be caused by the breadth of a system.   For example, consider the relatively simple product of a lawn service.  How many processes and steps are required to attract and sign-up customers, then secure the equipment and employees to perform the job, schedule the service, actually deliver the service and then to collect payment. The simple system becomes more complex as we broaden the scope of our understanding.  Add in the impact of a variable like weather or an employee calling in sick and things get interesting.  Really complicated systems such as the manufacturing and sale of an automobile can be quite mind numbing in its complexity.  The natural strategy when faced with this level of complexity is to focus on parts of the overall system. This can lead to optimizations that do not translate to the bottom line. A second natural strategy for dealing with complexity is to develop models. All models are abstractions, and while abstractions are needed, you need to strike a balance so that the ideas generated from studying the model or results of experiments or pilots run against the model are representative of results in the real world.  For example, let’s say you build a 1/8 scale replica of a server farm.  The replica is a model that could be used to study how the servers would be placed or used to plan how they would be accessed for service. This would be a valid use of a model.  But if the model was placed in the actual server room and the observation used to jump to the conclusion that since the model fit, the server farm would fit, a mistake could quite possibly be made. Because of the complexity, we tend to focus on a part of system or to make abstractions. However, both can make it hard to think about the big picture needed to apply systems thinking. 

The final difficulty with the use of systems thinking is the pressure of the day-to-day.  As I noted when I re-read The 7 Habits of Highly Effective People, the urgent and important issues of the day can easily overwhelm the important and but not urgent. The use of systems thinking and the systemic changes identified through the use of the tool will generally fall into the important but not urgent category.  A person who is having a heart attack due to cholesterol clogged arteries needs to deal with urgency of the attack before identifying and addressing their diet and other root causes. Leveraging systems thinking as a tool to address large-scale systemic issues is not a magic wand, rather a concept that will require time and effort to use.  If the organization is being overcome by day-to-day events, systems thinking will be difficult to use.  One technique that I have seen to deal with this scenario is to create a cross-functional, highly focused (tiger team) with a specific time box to start the process. This will require removing the team’s day-to-day responsibilities until the team meets it’s goal. This is a very difficult tactic to use as the people you would want on the team are generally the best at their job. This can potentially have a negatively impact organizational performance for a short period of time. You must consider the ROI.

The use of systems thinking is not for the faint of heart.  There are difficulties in applying the concept.  Boundaries, complexity and day-to-day pressures are the most significant, however there are others such as ensuring the team has system thinking training. Systems thinking can deliver a broad overall perspective and great value, but as a leader you must balance the difficulties with the benefits.

Categories: Process Management

Extending Small Basic with Function Procedures

Phil Trelford's Array - Thu, 01/09/2014 - 19:12

Microsoft Small Basic is a minimal implementation of the BASIC language aimed at beginners, with only 14 keywords.

A few years back I used Small Basic as an early introduction to programming for my 2 young children (at the time 9 and 5). Small Basic’s library has a nice simple API for drawing shapes and moving a turtle around the screen which the kids loved. However I found the lack of function arguments and return values was quite limiting from a teaching perspective. After creating shapes we wanted to refactor the code so that the drawing procedures could be parameterized, which can only be achieved with global state. Not wanting to get my kids in to bad habits early we swiftly moved on to F#.

Coincidentally Small Basic’s library is a .Net assembly that can be easily consumed from C#, F# and VB.Net, which I’ve used once while introducing C# programming to adult beginners.

Inspired by Small Basic’s simplicity, I’ve also built an open source library along similar lines called SmallSharp which I’ve used on occasion to introduce programming in F#. I feel the ability to start drawing shapes on the screen with just a few commands gives a real sense of excitement and achievement. The Processing language is another good option in this space. In contrast large frameworks like WinForms and WPF, although highly customizable, typically require a lot of work up front before you see any results.

In the previous three articles I’ve described steps to building a Small Basic compiler. First creating an abstract syntax tree (AST) with F# discriminated unions, then parsing with the FParsec parser combinator library and finally transforming to CIL with reflection emit.

In this article I’ll give some details on how I’ve extended the compiler with function procedures, bringing the functionality of Small Basic closer to that of VBScript.

The source code including the function procedure extension is available on BitBucket.

Extending the AST

First off the AST must be extended to support function declarations:

    | Sub of identifier * string list
    | EndSub
    // Language extensions
    | Function of identifier * string list
    | EndFunction

Next a way is needed to call functions:

and invoke =
    | Method of string * string * expr list
    | PropertyGet of string * string
    | Call of string * expr list // Language extension

Extending the Parser

Now the parser needs to recognise the new syntax:

let pparams = 
    between (str_ws "(") (str_ws ")") (sepBy pidentifier_ws (str_ws ","))
let pmethod = 
    pidentifier_ws .>>. opt pparams
    |>> (fun (name,ps) -> name, match ps with Some ps -> ps | None -> [])
let pfunction = 
    str_ws1 "Function" >>. pmethod |>> (fun (name,ps) -> Function(name,ps))
let pendfunction = 
    str_ws "EndFunction" |>> (fun _ -> EndFunction)

The Function keyword expects a method declaration which is composed of an identifier and optional parameters between parentheses.

Calls in expressions are recognized as a single identifier with a list of arguments:

let pcall = pidentifier_ws .>>. ptuple 
            |>> (fun (name,args) -> Call(name, args))

Code Generation

The code generator now needs to generate methods for both Sub and Function statements, with void and Primitive return values respectively. The generated methods may also have named arguments, passed by value. When an identifier is referenced in a statement the generator checks the method arguments in precedence to global fields. Finally return values are taken from the field with the same name as the method, as is the convention with the Visual Basic series of languages.


Here’s FizzBuzz in Small Basic utilizing the new extension:

' Returns Modulus
Function Modulus(Dividend,Divisor)
  Modulus = Dividend
  While Modulus >= Divisor
    Modulus = Modulus - Divisor

For A = 1 To 100 ' Iterate from 1 to 100
  Mod3 = Modulus(A,3) ' A % 3
  Mod5 = Modulus(A,5) ' A % 5
  If Mod3 = 0 And Mod5 = 0 Then
  ElseIf Mod3 = 0 Then
  ElseIf Mod5 = 0 Then


Extending the language touched small parts of the AST, parser and code generation steps. The whole process took only a couple of hours.

With the simple addition of function procedures with arguments and return values, Small Basic starts to approach the functionality of VBScript, and feel more like a grown up language for scripting.

It’s also starting to feel like the Small Basic AST and parser could be easily extended to support any of the Visual Basic family of languages, from VBScript to VBA to VB.Net.


Just as Small Basic currently has an export to VB.Net option, another interesting future direction might be to transform Small Basic programs to JavaScript allowing truly cross platform deployment.

Categories: Programming

Extreme Goal Setting for 2014

When’s the last time you went for your personal Epic Win?   If it’s been a while, no worries.  Let’s go big this year.

I’ll give you the tools.

I realize time and again, that Bruce Lee was so right when he said, “To hell with circumstances; I create opportunities.”  Similarly, William B. Sprague told us, “Do not wait to strike till the iron is hot; but make it hot by striking.” 

And, Peter Drucker said, “The best way to predict the future is to create it.”   Similarly, Alan Kay said, "The best way to predict the future is to invent it."

Well then?  Game on!

By the way, if you’re not feeling very inspired, check out either my 37 Inspirational Quotes That Will Change Your Life, Motivational Quotes, or my Inspirational Quotes.  They are intense, and I bet you can find your favorite three.

As I’ve been diving deep into goal setting and goal planning, I’ve put together a set of deep dive posts that will give you a very in-depth look at how to set and achieve any goal you want.   Here is my roundup so far:

Brian Tracy on 12 Steps to Set and Achieve Any Goal

Brian Tracy on the Best Times for Writing and Reviewing Your Goals

Commit to Your Best Year Ever

Goal Setting vs. Goal Planning

How To Find Your Major Definite Purpose

How To Use 3 Wins for the Year to Have Your Best Year Ever

The Power of Annual Reviews for Achieving Your Goals and Realizing Your Potential

What Do You Want to Spend More Time Doing?

Zig Ziglar on Setting Goals

Hopefully, my posts on goal setting and goal planning save you many hours (if not days, weeks, etc.) of time, effort, and frustration on trying to figure out how to really set and achieve your goals.   If you only read one post, at least read Goal Setting vs. Goal Planning because this will put you well ahead of the majority of people who regularly don’t achieve their goals.

In terms of actions, if there is one thing to decide, make it Commit to Your Best Year Ever.

Enjoy and best wishes for your greatest year ever and a powerful 2014.

Categories: Architecture, Programming

The Importance Of Finishing What You Started

Making the Complex Simple - John Sonmez - Thu, 01/09/2014 - 17:30

If you are like me you probably have a long history of projects that are 90% or less done. I’ve had a real problem in my life with finishing what I started.  But, once I actually started completing the things I started, I learned that the payoff for doing so is huge. In this video, […]

The post The Importance Of Finishing What You Started appeared first on Simple Programmer.

Categories: Programming

Beyond Budgeting – 15 Minutes on Air with Bjarte Bogsnes

NOOP.NL - Jurgen Appelo - Thu, 01/09/2014 - 12:28
Beyond Budgeting

An interview with Bjarte Bogsnes, author of Implementing Beyond Budgeting

The post Beyond Budgeting – 15 Minutes on Air with Bjarte Bogsnes appeared first on NOOP.NL.

Categories: Project Management

Elements of Project Success

Herding Cats - Glen Alleman - Thu, 01/09/2014 - 05:02

There are three key elements of every project on the planet - Cost, Schedule, and the performance of the product or service produced by the project. Each of these has drivers. The connections between Cost, Schedule, and Technical Performance are not Iron as suggested in the Iron Triangle of a PMI view of the project. Instead the connections are elastic, springy, flexible. But they are connected.

Screen Shot 2014-01-08 at 4.44.26 PMDrivers of the Three Elements

Cost is driven by:

  • Labor - how many people do we have on this project?
  • Materials - what's or raw material cost and what's the conversation rate for that material?
  • When we spend money, how effecient are we? What's our efficacy of funds? Do we get - at a minimum -  $1.00 in return for every $1.00 spent?
  • What's our overhead rate, our fully burdened costs of labor and materials?
  • What our other indirect costs? Benefits, facilities? 

These costs are themselves variable, as a function of the project phase, external forces for labor, materials, and overhead. But the cost variable starts with these.

Schedule is driven by:

  • The irreducible uncertainties of the work being performed. All work durations are random variables. The shape of the Probability Distribution Function can be known, but the exact probability of occurance of any one duration for any one task can not. So to protect from this uncertainty we need margin. Schedule margin, cost margin, techncial margin.
  • The reducible uncertainties are event based. There is a probability that the material we order will not arive as planned and we'll have a delay in our project and have to pay for labor waiting to start work. We can spend money to reduce or eliminate reducible uncertainty. There is a probability that when we test the new data based server with the actual data, it will not perform as needed. We can spend money and time to test the scalability of the database.
  • The capacity for work impacts schedule. We are not a clever as we thought. We are not as capable of working the planned number of hours as we thought. Our capacity of doing the work is impacted in ways we didn't think of.

Technical Performance is driven by:

  • Unrealistic expectations of the Effectiveness and Performance of the resutling technology
  • We have unanticipated risk.
  • Our solution doesn't scale, isn't as reliable as we need, is harder to repair, doesn't meet the technical, performance, or effectiveness goals.

So What Does All This Mean?

  • The three elements of a project are not independent.
  • One impacts others.
  • Two impact the third.
  • There are constant tradeoffs.
  • All elements are random processes, possibly known, sometimes unknown.

But for project success we need to have several things in place. The random behavior has to be knowable. It can't be chaos. If it is chaos, the project will fail, because there is no corrective action.

The three elements need to be known to some degree of confidence.

  • What's the target schedule.
    • When does the customer need to outcomes of the project?
    • What are the delivery times for the intermediate outcomes of the project, so the customer can look at them and determine if they are what was needed before its too late to correct them?
  • How much is this project going to cost when we're done?
    • How much money will we need along the way?
    • In exchange for this cost, what is the beneficial outcome, to offset the cost.
    • This is the fundamental  Return on Investment calculation ROI = (Benefit - Cost) / Cost. If we don't know the cost we can't know the value.
    • We may know the cost, because it is fixed, then we need to know the schedule and the value produced in exchange for that fixed cost and schedule in terms of capabilities.
  • What are we building?
    • Is it the right thing to build? How do we know? Do we have some Concept of Operations, a Statement of Work, or Statement of Objectives, sticky notes on the white, 3x5 cards, something that says what DONE looks like in units of measure meaningful to the decision makers.
  • How can we assure that what we're building meets the needs to the customer?
    • What the Measures of Effectiveness that state the operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions?
    • What are the Measures of Performance that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions?
    • What are the Key Performance Parameters that represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program?
    • What are the Technical Performance Measures that are the attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal?

Do know these to some degree of confidence, you don't know what DONE looks. The only measure of progress becomes the passage of time and consumption of money. It's unlikely any customer is going to be willing to pay you - at least for very long - to spend their money, without some understand of Cost, Schedule, and the resulting Technical Outcomes.


Related articles The "Real" Root Cause of IT Project Failure A Fundamental Principle In Managing Uncertainty The 5 P's of Project Management Success Both Aleatory and Epistemic Uncertainty Create Risk Five Core Processes of Project Success
Categories: Project Management

Integrity #3: A Testimonial

James Bach’s Blog - Thu, 01/09/2014 - 04:07

Oliver Erlewein is an automation specialist. He’s respected in the Context-Driven Testing community of New Zealand and has been an agitator pushing back against the ISTQB. After some years of frustration with bad management he finally went independent. Now he’s back to full-time work. He posted the following as a comment:

Starting 2014, I have given up my self-employment and joined a (sort of) start up. I didn’t think I was ever going back to being employed but this was worth it. I have found a company that respects my professionalism and listens to what I say, where I am responsible for what I produce and get the full control of how to go about it. I and the task I do are respected. The word integrity doesn’t get used here but it is a place that actually has oodles of it.

Every now and again I hear the sentence “you are the expert so what do you suggest we do?” or “do what you think is right, you are the expert” ….and they mean it exactly like that. It makes for a completely different working environment. It motivates, it invigorates and it makes working fun. It puts heaps more pressure and responsibility on me but I am happy as taking that on board because I am convinced that I can do it (even if I still don’t know how right at this moment).

Although this shop is not agile (but more agile than a lot of the shops out there that call themselves agile!) they do something that is one of the main success factors for agile: They re-introduce back the idea of responsibility, professionalism and craftsmanship into (IT) work. And that motivates. I feel like I can call bull**** if it is appropriate to do so or get traction on subjects I think are important.

So although it meant I made a career change away from my original trajectory I made it consciously towards a more ethical work life, where integrity and being the best you can actually counts for something.

Thank you for sharing that with us, Oliver. It goes to show that there are good managers out there who understand craftsmanship and leadership.


Categories: Testing & QA

Systems Thinking: Putting Systems Thinking To Work In Process Improvement

Systems thinking helps to make sure process improvement see the big picture.

Systems thinking helps to make sure process improvement see the big picture.

Why isn’t systems thinking one of the first techniques any IT change agent reaches for?   I would suggest that it begins with training.  Most Change Professionals have not been trained in applying systems thinking techniques because it is viewed as an engineering or academic practice. Systems thinking, while applicable to any type of system, has primarily been applied in science, engineering and social sciences. Systems thinking provides a framework for the introduction of lean techniques which have become popular in  evolving the practices of IT in the context of delivering maximum business value. Lean provides tool and philosophy, and systems thinking provides the breadth of scope to apply those tools.  Systems thinking provides process improvement with both a scope by defining what a system is and a business related goal for improvement, to improve the delivery of business value.

Affecting processes, systems and the environmental elements that are outside of the change agent’s control is difficult, requiring the development of influence and political capital outside of their comfort zone. For example, in an organization that is delivering a product that requires a hardware and software combination, a change that shortens the length of time needed to deliver the software may not impact the delivery time of the product, if the hardware development does not keep pace. For another example consider a set of process improvements meant to quicken the pace of requirements definition and evolution that feed into a classic stage gate for approval. Changes can be made moot by department boundaries within IT as easy as by processes and systems outside of IT. An example, a few years ago, I observed a group of business analysts who embraced an iterative process for requirements elicitation, but still had to provide a single complete requirements definition document before the project could progress.  They had not been able to engage the owner of the stage gate process to fashion a scenario in which parts could be passed through the barrier as they were completed. Therefore little of the increase pace was transmitted to the overall process.

Process improvement begins by identifying  opportunities. In order to use a systems thinking approach to process improvement we need to ensure that the boundary for process improvement is a whole system, a whole value chain and provides the means to affect the output of the whole system. This helps ensure that any changes improve the overall performance of IT. One, simple approach I use to identify systems thinking process improvement opportunities begins by assembling a cross-functional team (or teams, for large supply chain systems) that includes representatives with experience from the whole system – beginning to end.  This is similar to the process described in our discussion of value chain mapping. I facilitate the team through one or two sessions using a combination of affinity diagramming (brainstorming and mute-grouping) and mind mapping in order to identify the variables impacting the system.  Affinity diagramming is a technique of driving out and grouping large amounts of data though the use of seed questions and brainstorming, followed by team grouping exercise done without talking.  Mind mapping is then leveraged to mine the data for non-linear relationships and to prompt for completeness.  Combining the two techniques (mind mapping and affinity diagramming) with the cross functional team leads to taking a holistic approach to making change. After we drive out the variables, I have the team work through a building a desktop model to identify which variables the team feels will impact the ultimate performance of the system.  For the variables selected, I ask the team to identify trends underway in these variables and any external trends that impact these trends.  This generally requires a bit of research and the collection of performance data for the variables. Experimentation is used to determine if the identified variables will have a positive impact on the output of the system being studied. Examples of experimentation techniques include building mathematical models and process pilots.

Systems thinking is a powerful concept. However, the breadth of vision required to address even the small process improvements will incent many managers to stay focused on their individual part of the process.  We have been taught that focusing on specific issues will help us improve what we do over time. Unfortunately, focusing on a narrow view of a complex system rarely provides enough information to affect overall customer experience or satisfaction. When improving development and maintenance processes, what really matters is that we deliver what we promised, when we promised and for what we promised. Then be in a position to do that as many times as required.  That last requirement means that our interactions, processes and people must be consumed in a holistic and sustainable manner. Building a backlog of process and human debt by focusing steps rather than the whole does not deliver sustainable products.

Categories: Process Management

Pixowl is looking for testers for their upcoming game Grub!

Fred Beringer - Wed, 01/08/2014 - 22:38

grub Pixowl is looking for testers for their upcoming game Grub!

A few months ago, I’ve met the founders of a mobile game development studio based in San Francisco, CA (they also have teams in Paris and Argentina): Pixowl (backed by a lot of tech entrepreneurs)  Not only are they the nicest people I’ve met in a long time but they’re also extremely talented! A great combo to start a friendship! Adrien is one of the best mobile developer I know and Laurel is a great artist doing all the illustration for their games (and has a very cool blog showcasing her work)

Today, they have a very successful Minecraft type of game which is doing really good on the Apple Store and they’re working on the second version of their other flagship game: Greedy Grub. Some of you might remember Snake from the early 80′s. This new version of Grub is Snake on mobile steroid!

From this:


snake Pixowl is looking for testers for their upcoming game Grub!

to this!

grub2 Pixowl is looking for testers for their upcoming game Grub!

My kids played the first version of the game and you can bet that when they’ve heard that the second version was on the horizon, they wanted to be involved! They’re the perfect beta testers and provide tons of feedback (Pixowl uses HockeyApp to manage the beta of Grub which has a very nifty feature to add feedback directly in the game. Very handy!)

There is today only one playable level but Grub is already very addictive. I had a glimpse of what’s coming and I think I will soon get rid of candy crush!

If you like games and want to be involved in the feedback process, join the Grub beta today!

Note: I have no affiliation with pixowl. I just like games, testing and Adrien makes really good crepes!

Get Shareaholic

Related posts:

  1. Thanks to Game Changers, Software Testing is flying high !
  2. QTP, leave them mobile testers alone
  3. The Cloud: A game changer to test, at scale and in production, SOA based web and mobile applications.
  4. Get involved with SOASTA CloudTest Mobile Development!
  5. Join the SOASTA TouchTest Movement next week!

Categories: Testing & QA

Under Snowden's Light Software Architecture Choices Become Murky

Adrian Cockcroft on the future of Cloud, Open Source, SaaS and the End of Enterprise Computing:

Most big enterprise companies are actively working on their AWS rollout now. Most of them are also trying to get an in-house cloud to work, with varying amounts of success, but even the best private clouds are still years behind the feature set of public clouds, which is has a big impact on the agility and speed of product development

While the Snowden revelations have tattered the thin veil of trust secreting Big Brother from We the People, they may also be driving a fascinating new tension in architecture choices between Cloud Native (scale-out, IaaS), Amazon Native (rich service dependencies), and Enterprise Native (raw hardware, scale-up).

This tension became evident in a recent HipChat interview where HipChat, makers of an AWS based SaaS chat product, were busy creating an on-premises version of their product that could operate behind the firewall in enterprise datacenters. This is consistent with other products from Atlassian in that they do offer hosted services as well as installable services, but it is also an indication of customer concerns over privacy and security.

The result is a potential shattering of backend architectures into many fragments like we’ve seen on the front-end. On the front-end you can develop for iOS, Android, HTML5, Windows, OSX, and so on. Any choice you make is like declaring for a cold war power in a winner take all battle for your development resources. Unifying this mess has been the refuge of cloud based services over HTTP. Now that safe place is threatened.

To see why...

Categories: Architecture

Placing Rules on Self-Organizing Teams

Mike Cohn's Blog - Wed, 01/08/2014 - 17:43

Many of the challenges in agile and Scrum stem from the idea of the self-organizing team. Of course, many (perhaps most) of the benefits are also the result of self-organizing teams.

One of the questions I get from many leaders is whether it's OK to mandate the team do something like use a particular tool, comply with a coding standard, or such.

Absolutely. A leader in the organization has the right to mandate anything like this. I've even seen a CEO who couldn't tell you a single difference between Java and COBOL who insisted her team use Java. And I supported her in that decision. This was back in 2000 when Sun Microsystems had announced their $100 million "Java Fund" of VC money to companies if they used Java. So this CEO had a reason for her mandate.

So, if you're a leader in your company and have the organizational clout to make dictates: Go ahead.

But, be careful. You can give the team any rule you want, but if you give them one rule too many, they'll shut down. They will go from self-organizing to feeling, "Management just tells us what to do." And there is a very fine here--quite literally one rule too many will push a team over the precipice.

Choose your rules wisely. Mandate that the team follow some coding standard that they determine? I've asked for that. Insist that all five teams in the company figure out and use a common testing tool. I've asked for that. Both of the applications the company produce must use the same main JavaScript library so programmers can help those on other teams. Yep, I've asked for that, too.

But, I've also seen management mandate things that didn't make sense when the risk of pushing the team out of the realm of self-organization was considered. One PMO insisted all daily scrums occur between 9 AM and noon. This was so the PMO could prepare reports based on the results of the daily scrums. (And, yes, that was a bad idea, too.)

So, when placing a rule on a team, consider it carefully. Any one rule could push them over the edge. It won't necessarily be that rule--in fact, the rule that pushes them over could be a worthwhile rule. It will generally be the overall quantity of the rules that creates the problem.

For each rule, consider whether that rule alone is worth the risk. If it's not, don't put the rule in place. Also, any time you consider adding a rule to a team, see if there's another rule (or constraint on how they work) that you can remove. Otherwise rules build up over time. It's good to periodically review all rules you've placed on teams and see if any have outlived their usefulness.

Choose wisely.

Quote of the Day

Herding Cats - Glen Alleman - Wed, 01/08/2014 - 17:09

Next time someone complains that you have made a mistake, tell them that may be a good thing. Because without imperfection, neither you nor I would exist - Stephen Hawking.

Courtesy Don Yeager's daily posts

Categories: Project Management

Tag Them! Tag Them All! Tag Them Now!

NOOP.NL - Jurgen Appelo - Wed, 01/08/2014 - 17:00
Tag Them All

I have 8,069 contacts in my database now, and 40 different tags. Many of those people are tagged because, for years, I have been keeping track of my connections to other people.

The post Tag Them! Tag Them All! Tag Them Now! appeared first on NOOP.NL.

Categories: Project Management

Seven Immutable Activities of Project Success

Herding Cats - Glen Alleman - Wed, 01/08/2014 - 16:49

There are Principles, Practices, and Processes of project success. I have a book coming that describes them. These are independent of any method, any domain, any favorite tool, buzz words, or personal paradigm. Much research on Root Causes of project failure have led to these Principles, Practices, and Processes. The Principles don't change, can't change. The Practices need to be tailored to the needs of the project and its paradigm. The Processes are localized.

But around these are 7 Activities of any project, that if not performed in some way, the probability of success is reduced, sometimes to Zero.

  1. Plan the scope of work.
  2. Break down the project scope of work into finite pieces that can be assigned to a responsible person or an organization for control of the technical, schedule, and cost objectives.
  3. Integrated the project work scope, schedule, and cost objectives into an agreed upon plan against which accomplishments can be measured. Control the changes to this plan.
  4. Capture the actual costs of doing the work and record the accomplishments produced by this work in units of measure meaningful to the decision makers.
  5. Objectively assess the accomplishments at the level the work is performed in those same units of measures
  6. Analyze any significant variances from the plan, forecast the impacts of these variances, and prepare an Estimate At Completion based on the performance to date of the work performed. Define corrective actions.
  7. Report this information to the project team and customer, so agreement on corrective actions can result.

Domain and Context

No matter if your building bridges across rivers, a flying machine to Mars, the next anti-virus drug, or writing software using Scrum for your internal web site, these activities must take place in some way. 

  1. Scope - We can't have a project if we don't have some notion of what DONE looks like. What does the customer want the result to do? What capabilities does the customer want to possess when the project is complete. If the customer doesn't know, then money and time has to be spent to discover this. The Agile development method spends money to discover the requirements. This is many times the right thing to do. But time and money have to be spent.
  2. Work Breakdown - As we discover what DONE looks like it may change. This is the nature of projects. As we discover new descriptions of DONE, the breakdown of the work has to change with it, otherwise those performing the work, won't know what the new DONE looks like.
  3. Integrating People and Work - this is a straight forward process. Assign people to work. The key is self-organizing, can't be the same as self-directed. Direction comes from external sources. Organization comes from internal sources. 
  4. Capture Costs - how much something costs is compared against how much something was planned to cost. This feedback provided steering inputs for future cost forecasting. Without this feedback there is not learning process, some not improvement is possible without feedback learning.
  5. Assess accomplishments - the only true assessment of accomplishment comes from customer feedback. Did the delivered product or service fulfil the needed capabilities? Measures of Effectiveness are the assessment of those capabilities.
  6. Analyze variances - with a plan and the actuals, you can get feedback from your performance. This is fundamental in all project domains. Kent Beck's quote optimism is the disease of software development, feed back is the cure, is applicable to all project domains, not just software.
  7. Report actionable information - with the variances against plan, you can then take corrective actions to get back on plan. 

Without the last 4 activities, you're managing the project open loop. This might be OK if your customer doesn't care how much it will cost or how long it will take to finish the defined work. But of they do, you'll need a target cost and a target completion date, the feedback that you're making progress to  those values. And of course some confidence that those targets are credible, their degree of variance, and how they are changing as the project progresses.

Open Closed Loop


So one final comment

When we hear that we don't need to estimate, there is no way to have a closed loop control system. Without on estimate of the cost, schedule, and technical performance goals, the only management control system is open loop. This is unlikley to lead to success for any non-trivial project.

Related articles Sources of Variance Evidence of 5 Immutable Principles of Project Success Risk Management for Dummies
Categories: Project Management

Systems Thinking: Habits Of A Systems Thinker

Sometimes you have to seek a little harder to understand the big picture.

Sometimes you have to seek a little harder to understand the big picture.

We should be guided by theory, not by numbers. – W.E. Deming Many process improvement programs falter when, despite our best efforts, they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. Systems thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather than simply events.  Systems thinking is all about the big picture. Grasping the big picture is important when approaching any change program.  It becomes even more critical when the environment you are changing is complex and previous attempts at change have been less than successful. The world that professional developers operate within is complex. Even though the goal of satisfying the projects stakeholders, on the surface, seems so simple. Every element of our work is part of a larger system that visibly and invisibly shapes our individual and organizational opportunities and risks.  The combination of complexity and the nagging issues that have dogged software-centric product development and maintenance suggest that real innovation will only come through systems thinking. Systems thinking requires thinking broader.  The Waters Foundation, a group dedicated to applying systems thinking to education, suggests a set of “Habits of a Systems Thinker.” The habits[1] are:

  • Seeking to understand the big picture
  • Observing how elements within systems change over time, generating patterns and trends
  • Recognizing that a system’s structure generates its behavior
  • Identifying the circular nature of complex cause and effect relationships
  • Changing perspectives to increase understanding
  • Surfacing and tests assumptions
  • Considering an issue fully and resists the urge to come to a quick conclusion
  • Considering how mental models affect current reality and the future
  • Using understanding of system structure to identify possible leverage action
  • Considering both short and long-term consequences of actions
  • Finding where unintended consequences emerge
  • Recognizing the impact of time delays when exploring cause and effect relationships
  • Checking results and changes actions if needed: “successive approximation”

These habits illustrate to really create change you need to take the overall process into account and test all of our assumptions before you can know that your change is effective. An example presented at MIT’s System Design and Management (SDM) program on Oct. 22 and 23 exposed the need to address complexity through holistic solutions. A hospital scenario was described in which alarm fatigue has occurred leading to negative patient outcomes.[2]  Alarm fatigue occurs when health professionals are overwhelmed by monitoring medical devices that provide data and alerts.  The devices don’t interoperate therefore all of the data and alerts just create noise which can hide real problems.  Any IT manager that has reviewed multiple monthly project status reports and updates can appreciate how a specific problem signal could be missed and what the consequences might be. Systems thinking applied through the filter of the “Habits of a Systems Thinker” is tailor-made to help us conceptualize, understand and then address complex problems; to find solutions for problems that seem elusive or that reoccur in an organization.

[1] [2]
Categories: Process Management

Sponsored Post: Netflix, Logentries, Host Color, Booking, Apple, ScaleOut, MongoDB, BlueStripe, AiScaler, Aerospike, LogicMonitor, AppDynamics, ManageEngine, Site24x7

Who's Hiring?
  • Apple is hiring for multiple positions. Imagine what you could do here. At Apple, great ideas have a way of becoming great products, services, and customer experiences very quickly.
    • Sr Software Engineer. The iOS Systems Team is looking for a Software Engineer to work on operations, tools development and support of worldwide iOS Device sales and activations. Please apply here
    • Sr. Security Software Developer. We are looking for an excellent programmer who's done extensive security programming. This individual will participate in various security projects from the start to the end. In addition to security concepts, it's important to have intricate knowledge of different flavors of Unix operating systems to develop code that's compact and optimal. Familiarity with key exchange protocols, authentication protocols and crypto analysis is a plus. Please apply here.
    • Senior Server Side Engineer. The Emerging Technology team is looking for a highly motivated, detail-oriented, energetic individual with experience in a variety of big data technologies.  You will be part of a fast growing, cohesive team with many exciting responsibilities related to Big Data, including: Develop scalable, robust systems that will gather, process, store large amount of data Define/develop Big Data technologies for Apple internal and customer facing applications. Please apply here.
    • Senior Server Side Engineer. The Emerging Technology team is looking for a highly motivated, detail-oriented, energetic individual with experience in a variety of big data technologies.  You will be part of a fast growing, cohesive team with many exciting responsibilities related to Big Data, including: Develop scalable, robust systems that will gather, process, store large amount of data Define/develop Big Data technologies for Apple internal and customer facing applications. Please apply here.
    • Senior Engineer: Emerging Technology. Apple’s Emerging Technology group is looking for a senior engineer passionate about exploring emerging technologies to create paradigm shifting cloud based solutions. Please apply here

  • The Netflix Cloud Performance Team is hiring. Help tackle the more complex scalability challenges emerging on the cloud today, wrangling tens of thousands of instances, handling billions of requests a day. We are searching for a Senior Performance Architect and a Senior Cloud Performance Tools Engineer

  • We need awesome people @ - We want YOU! Come design next generation interfaces, solve critical scalability problems, and hack on one of the largest Perl codebases. Apply:

  • UI EngineerAppDynamics, founded in 2008 and lead by proven innovators, is looking for a passionate UI Engineer to design, architect, and develop our their user interface using the latest web and mobile technologies. Make the impossible possible and the hard easy. Apply here.

  • Software Engineer - Infrastructure & Big DataAppDynamics, leader in next generation solutions for managing modern, distributed, and extremely complex applications residing in both the cloud and the data center, is looking for a Software Engineers (All-Levels) to design and develop scalable software written in Java and MySQL for backend component of software that manages application architectures. Apply here.
Fun and Informative Events
  • Your amazing event here.
Cool Products and Services
  • Log management made easy with Logentries Billions of log events analyzed every day to unlock insights from the log data the matters to you. Simply powerful search, tagging, alerts, live tail and more for all of your log data. Automated AWS log collection and analytics, including CloudWatch events. 

  • HostColorCloud Servers based on OpenNebula Cloud automation IaaS. Cloud Start features: 256 MB RAM; 1000 GB Premium Bandwidth; 10 GB fast, RAID 10 protected Storage; 1 CPU Core;  /30 IPv4 (4 IPs) and /48 IPv6 subnet and costs only $9.95/mo. Client could choose an OS (CentOS is default). 

  • LogicMonitor is the cloud-based IT performance monitoring solution that enables companies to easily and cost-effectively monitor their entire IT infrastructure stack – storage, servers, networks, applications, virtualization, and websites – from the cloud. No firewall changes needed - start monitoring in only 15 minutes utilizing customized dashboards, trending graphs & alerting

  • Rapidly Develop Hadoop MapReduce Code. With ScaleOut hServer™ you can use a subset of your Hadoop data and run your MapReduce code in seconds for fast code development and you don’t need to load and manage the Hadoop software  stack, it's a self-contained Hadoop MapReduce execution environment. To learn more check out

  • MongoDB Backup Free Usage Tier Announced. We're pleased to introduce the free usage tier to MongoDB Management Service (MMS). MMS Backup provides point-in-time recovery for replica sets and consistent snapshots for sharded systems with minimal performance impact. Start backing up today at

  • BlueStripe FactFinder Express is the ultimate tool for server monitoring and solving performance problems. Monitor URL response times and see if the problem is the application, a back-end call, a disk, or OS resources.

  • Aerospike Capacity Planning Kit. Download the Capacity Planning Kit to determine your database storage capacity and node requirements. The kit includes a step-by-step Capacity Planning Guide and a Planning worksheet. Free download.

  • aiScaler, aiProtect, aiMobile Application Delivery Controller with integrated Dynamic Site Acceleration, Denial of Service Protection and Mobile Content Management. Cloud deployable. Free instant trial, no sign-up required.

  • ManageEngine Applications Manager : Monitor physical, virtual and Cloud Applications.

  • : Monitor End User Experience from a global monitoring network.

If any of these items interest you there's a full description of each sponsor below. Please click to read more...

Categories: Architecture

Ten 2013 Software Architecture Videos to Watch

From the Editor of Methods & Tools - Tue, 01/07/2014 - 14:03
Software architecture is a fundamental discipline in the software development world. Even if this activity was sometimes performed out of an ivory tower, good software architecture is a key element for the long term quality and good evolution of software systems. Software architecture documentation allows also helpt to communicate the vision of the system to the software development team. Here are, in no particular order, ten presentations on software architecture from last year software development conferences that are available on videos and that can help you understand the current trends in ...