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

Want to Accomplish Your Goals? Become a Finisher

Making the Complex Simple - John Sonmez - Mon, 12/29/2014 - 17:00

It was 2:00 AM. I hadn’t slept much in the past few days, but I was done. After months of work, I was finally ready to ship. I uploaded the final version of PaceMaker to the Android App store and clicked “publish.” I didn’t know it at the time, but this day would delineate a new chapter of my life. ... Read More

The post Want to Accomplish Your Goals? Become a Finisher appeared first on Simple Programmer.

Categories: Programming

How Do You Serve Your Organization?

A recent coaching client was concerned about the progress his team was making—or really, the lack of progress his team was making. We spoke about the obstacles he had noticed.

“The team doesn’t have time to write automated tests. As soon as they finish developing or testing a feature, people get yanked to another project.”

“Are people, developers and testers, working together on features?” I wanted to know.

“No, first a developer works on a feature for a few days, then a tester takes it. We don’t have enough testers to pair them with developers. What would a tester do for three or four days, while a developer worked on a story?”

“So, to your managers, it looks as if the testers are hanging around, waiting on developers, right?” I wanted to make sure I understood at least one of his problems.

“Yes, that’s exactly the problem! But the testers aren’t hanging around. They’re still working on test automation for stories we said were done. We have more technical debt than ever.” He actually moaned.

“Would you like some ideas? It sounds as if you are out of ideas here.” I checked with him.

“Yes, I would!” He sounded grateful.

These were the ideas I suggested:

  1. Don’t mark stories as done, unless they really are done, including all the automated tests. You might need a kanban board instead of a Scrum board, to show your workflow to yourselves, inside the team.
  2. Work as developer-tester pairs, or even better, developer-developer-tester triads. Or, add even more developers, so you have enough developers to complete a story in a day or so. When the developers are done, they can see if the tester needs help with test automation hooks, before they proceed to another story.
  3. Make sure the product owner ranks all the stories in an iteration, regardless of which product the stories belong to. That way the team always works together, the entire iteration.

I asked him if he could do these things for the team. He said he was sure he could. I’d been coaching him for a while. He was pretty sure he could coach his team.

Now I asked him the big question. Could he influence the project portfolio work at the level above him? His managers were too involved in who was doing what on the teams, and were not ranking the projects in the project portfolio. He needed to influence the managers to flow work through the team, and not move people like chess pieces. Could he do that?

He and I started to work through how and who he could influence.

Technical leads, first- and middle-managers may find influence more challenging. You have to build rapport and have a relationship before you influence people. Had he done that yet? No, not yet.

You often need to serve your organization at several levels. It doesn’t matter if you are a technical leader, or someone with manager in your title. Rarely can you limit your problem-solving to just your team.

If these challenges sound like yours, you should consider joining Gil Broza and me in the Influential Agile Leader in either San Francisco or London next year. It’s an experiential event, where you bring your concerns. We teach a little, and then help you with guided practice. It’s a way to build your servant leadership and learn how to coach up, down, and sideways. It’s a way to learn who and how to influence. We have more sessions, so you can bring your issues and address them, with us and the other participants.

Our early bird pricing expires Dec 31, 2014. Please join us at Influential Agile Leader.

Categories: Project Management

The International Obfuscated Clojure Coding Contest

Maurits Thinks Aloud - Maurits Rijk - Mon, 12/29/2014 - 12:31

While some people may argue that Clojure is already obfuscated by default, I think it is about time to organise an official International Obfuscated Clojure Coding Contest similar to the IOCCC. This idea was born out of my own attempts to fit my Clojure experiments in one single tweet, that is 140 characters.

Winning IOCCC entry: flight simulator

The plan

First get some feed back from the Clojure community on this idea. You are invited to share your thoughts as comments to this blogpost. I will also twitter about this idea. If this particular tweet will get 100+ retweets, I will go ahead with the next step in the plan, which is establishing the rules for this contest.

These rules are also open to discussion. At the moment I’m considering for example a category ‘Code fits in a single tweet’ and another one like ‘Code size is limited to 1024 characters’.

After these preliminary steps I will set up a website, find a jury to judge the submissions and will continue from there.

Inspiration

Since Clojure is such a powerful language, there are also plenty opportunities to make the code more challenging to read. Mike Anderson already created a GitHub project called clojure-golf with some tricks.

You are also invited to violate the first rule of the macro club: Don’t write macros. And obviously the second rule (write macros if that is the only way to encapsulate a pattern) should be ignored as well.

Also extending datatypes in unexpected ways is alway a good idea. See for example my answer to this StackOverflow question about ‘an idiomatic clojure way to repeat a string n times‘.

Generating code on the fly is of course a breeze in a ‘code-as-data’ language like Clojure.

Finally

So if you think you can create a fully functional chess engine in 1024 characters, a Java interpreter in a single tweet or managed to make the Clojure REPL self-conscious with your obfuscated code, leave a comment. Also if you have suggestions for rules, want to help with setting up a website, want to be a judge or want to help in another way, I would love to hear from you.

And most importantly: have fun!


Quote of the Day

Herding Cats - Glen Alleman - Mon, 12/29/2014 - 00:22

Nothing predicts the future as much as past impunity

When allowed - or even encouraged - to deliver late, over budget, with outcomes failing meet needed capabilities of those paying for those outcomes with no corrective actions to processes, technology, or the people applying them, then future disappointments are not far away.

Categories: Project Management

SPaMCAST 322 – Clareice and Clyneice Chaney, Contracting, Acquisition and Agile Testing

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 322

SPaMCAST 322 features our interview with Clareice and Clyneice Chaney. Clareice and Clyneice provide insights and practical advice into how Agile and contracting work together.  The focus of the interview is on contracting and acquisition of Agile testing, however the concepts we discussed can be applied to contracting for any type of service using Agile techniques.

Clyneice Chaney brings over 30 years of testing, quality assurance, and process improvement experience. Clyneice holds certifications from the American Society for Quality as a Certified Quality Manager/Organizational Excellence and Project Management Institute’s Professional Project Manager. She has participated as an examiner for Baldrige state quality awards for Georgia and Virginia. She is currently an instructor for an International Testing Certification organization and has presented technical papers at the Software Engineering Institute: SEPG Conference, American Society for Quality: Quality Manager’s conference, Quality Assurance Institute International Testing Conference, International Conference on Software Process Improvement and Software Test and Performance Testing Conferences.

Clareice Chaney has over 30 years’ experience in Commercial and Government Contracting with an emphasis in contracting within the information technology arena.  She holds a PMP certification with the Project Management Institute and is a certified Professional Contracts Manager (CPCM) through the National Contract Management Association (NCMA). She has presented at the National Contract Management Association World Congress and provided recent collaborations on agile testing and contracting at the Quality Assurance Institute International Conferences.

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

The next Software Process and Measurement Cast will feature our essay on the Attributes Leading to Faiure with Agile. Agile projects don’t work when there isn’t open and honest communication within a team. Problems also can occur when all team members are not involved, or if the organization has not bought into the principles of Agile. Knowing what can go wrong with Agile implementations and projects is a step to making sure they do not happen!

We will also have the next Form Follows Function column from Gene Hughson and Explaining Change with Jo Ann Sweeney.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.


Categories: Process Management

SPaMCAST 322 – Clareice and Clyneice Chaney, Contracting, Acquisition and Agile Testing

Software Process and Measurement Cast - Sun, 12/28/2014 - 23:00

SPaMCAST 322 features our interview with Clareice and Clyneice Chaney. Clareice and Clyneice provide insights and practical advice into how Agile and contracting work together.  The focus of the interview is on contracting and acquisition of Agile testing, however the concepts we discussed can be applied to contracting for any type of service using Agile techniques.

Clyneice Chaney brings over 30 years of testing, quality assurance, and process improvement experience. Clyneice holds certifications from the American Society for Quality as a Certified Quality Manager/Organizational Excellence and Project Management Institute's Professional Project Manager. She has participated as an examiner for Baldrige state quality awards for Georgia and Virginia. She is currently an instructor for an International Testing Certification organization and has presented technical papers at the Software Engineering Institute: SEPG Conference, American Society for Quality: Quality Manager's conference, Quality Assurance Institute International Testing Conference, International Conference on Software Process Improvement and Software Test and Performance Testing Conferences.

Clareice Chaney has over 30 years’ experience in Commercial and Government Contracting with an emphasis in contracting within the information technology arena.  She holds a PMP certification with the Project Management Institute and is a certified Professional Contracts Manager (CPCM) through the National Contract Management Association (NCMA). She has presented at the National Contract Management Association World Congress and provided recent collaborations on agile testing and contracting at the Quality Assurance Institute International Conferences.

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

The next Software Process and Measurement Cast will feature our essay on the Attributes Leading to Faiure with Agile. Agile projects don’t work when there isn’t open and honest communication within a team. Problems also can occur when all team members are not involved, or if the organization has not bought into the principles of Agile. Knowing what can go wrong with Agile implementations and projects is a step to making sure they do not happen!

We will also have the next Form Follows Function column from Gene Hughson and Explaining Change with Jo Ann Sweeney.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Categories: Process Management

R: Featuring engineering for a linear model

Mark Needham - Sun, 12/28/2014 - 22:55

I previously wrote about a linear model I created to predict how many people would RSVP ‘yes’ to a meetup event and having not found much correlation between any of my independent variables and RSVPs was a bit stuck.

As luck would have it I bumped into Antonios at a meetup a month ago and he offered to take a look at what I’d tried so far and give me some tips on how to progress.

The first thing he pointed out is that that all my features were related to date/time and that I should try and generate some other features. He suggested I start with the following:

  • info about organisers (quantify popularity of organisers, how many people work for them)
  • info about the venue (how many people fit there, how far it is from the centre of the city)
  • number of tweets for the event, during X days before the event

I’d read a lot on Kaggle forums about how feature engineering was the most important part of building statistical models but it didn’t click what that meant until Antonios pointed it out.

The first thing I decided to do was bring in the data for all London’s NoSQL meetups rather than just the Neo4j one to give myself a bit more data to work with.

Group Membership

Having done that, it seemed from visual inspection that the meetup groups with the most members (i.e. Data Science London, Big Data London) seemed to get the biggest turnouts.

I thought it’d be interesting to see what the correlation was between group membership and RSVPs so this was the first new feature I added.

I generated this feature by a combination of a Neo4j query and R code which resulted in this data frame as CSV file.

We can quickly preview it to see some of the events and the group membership at that time:

> df = read.csv("/tmp/membersWithGroupCounts.csv")
> df$eventTime = as.POSIXct(df$eventTime)
> df %>% sample_n(10) %>% select(event.name, g.name, eventTime, groupMembers, rsvps)
 
                                                                  event.name                                   g.name           eventTime groupMembers rsvps
23  Scoring Models, Apache Drill for querying structured & unstructured data                      Data Science London 2014-09-18 18:30:00         3466   159
421                                                      London Office Hours                London MongoDB User Group 2012-08-22 17:00:00          468     6
304                            MongoDB University Study Group London Meet up                London MongoDB User Group 2014-07-16 17:00:00         1256    23
43                                                           December Meetup          London ElasticSearch User Group 2014-12-10 18:30:00          721   126
222                                                          Intro to Graphs                Neo4j - London User Group 2014-09-03 18:30:00         1453    39
207                              Intro to Machine Learning with Scikit-Learn                            Women in Data 2014-11-11 18:15:00          574    41
168                                        NoSQL panel and LevelDB + Node.js                             London NoSQL 2014-04-15 18:30:00          183    51
443                                                      London Office Hours                London MongoDB User Group 2012-11-29 17:00:00          590     3
79                                  Apache Cassandra 1.2 with Jonathan Ellis                         Cassandra London 2013-03-06 19:00:00          399    95
362                                                          Span conference Span: scalable and distributed computing 2014-10-28 09:00:00           67    13

One thing I found difficult was finding features specific to an event – I’m not sure how much that matters. I generated features for the venue or group much more easily.

First let’s see if there’s actually any correlation between these two variables by plotting them:

ggplot(aes(x = groupMembers, y = rsvps), data = df) + 
  geom_point()
2014 12 28 21 02 21

It looks like there’s a positive correlation between these two variables but let’s create a single variable linear model to see how much of the variation is explained:

> fit = lm(rsvps ~ groupMembers, data = df)
> fit$coef
 (Intercept) groupMembers 
 20.03579637   0.05382738

Our linear model equation is therefore:

rsvps = 20.03579637 + 0.05382738(groupMembers)

Let’s see how well correlated our predicted RSVPs and actual RSVPs are:

> df$predictedRSVPs = predict(fit, df)
> with(df, cor(rsvps, predictedRSVPs))
[1] 0.6263096

Not too bad! There is quite a strong correlation between these variables although it’s not perfect.

Hours into the day

In my first model I’d treated time as a categorical variable but Antonios pointed out that it’s often easier to understand the relationship between variables if they’re both continuos so I transformed the event time like so:

df$hoursIntoDay = as.numeric(df$eventTime - trunc(df$eventTime, "day"), units="hours")

Let’s see how that plots against the RSVP count:

ggplot(aes(x = hoursIntoDay, y = rsvps), data = df) + 
  geom_point()
2014 12 28 21 27 48

It’s a bit more difficult to see a trend here as there are quite discrete times at which events happen and the majority start at 6.30 or 7.00. Nevertheless let’s build a linear model with just this variable:

> fit = lm(rsvps ~ hoursIntoDay, data = df)
> fit$coef
 (Intercept) hoursIntoDay 
   -18.79895      4.12984 
> 
> df$predictedRSVPs = predict(fit, df)
> with(df, cor(rsvps, predictedRSVPs))
[1] 0.181472
Distance from the centre of London

Next up I tried a feature based on the location of the venue that the events were held at. The hypothesis was that if a venue was closer to the centre of London then people would be more likely to attend.

To calculate this distance I used the distHaversine function from the geosphere package as shown in a previous blog post.

Let’s have a look at the graph for that variable:

ggplot(aes(x = distanceFromCentre, y = rsvps), data = df) + 
  geom_point()
2014 12 28 21 37 41

It’s hard to tell much from this plot, mainly because a majority of the points are clustered around the 2,500 metre mark which represents Shoreditch venues. Let’s plug it into a linear model and see what we come up with:

> fit = lm(rsvps ~ distanceFromCentre, data = df)
> fit$coef
       (Intercept) distanceFromCentre 
      57.243646619       -0.001310492 
> 
> df$predictedRSVPs = predict(fit, df)
> with(df, cor(rsvps, predictedRSVPs))
[1] 0.02999708

Interestingly there’s barely any correlation here which was surprising to me. I tried combining this variable in a multiple variable model with the others but it still didn’t have much impact so I think we’ll park this one for now.

This is as much as I’ve done at the moment and despite spending quite a bit of time on it I still haven’t really explained very much of the variation in RSVP rates!

I have managed to identify some ways that I was able to come up with new features to try out though:

  • Read what other people are doing e.g. I have some ideas for lag variables (e.g. how many people went to your previous meetup) having read about this baseball linear model
  • Talk to other people about your model – they often have ideas you wouldn’t think of being too deep into the problem.
  • Look at what data you already have and try and incorporate that and see where it leads

The next avenue I started exploring is topic modelling as I have a hypothesis that people RSVP for events based on the content of talks but I’m not sure of the best way to go about that.

My current thinkins is are to pull out some topics/terms by following the example from Chapter 6 of Machine Learning for Hackers.

Categories: Programming

There’s Magic in the Air

This is a follow up to Santa Lands on a Virgin Atlantic Plane with 4D Technology.  It turns out that you can measure the magic in the air.

Here is the page that’s tracking the festive magic:

There’s Magic in the Air

Here is a snapshot of the page:

image

 

How are we measuring the festive magic?  Using cloud-based Dynamics social analytics software.

Via the There’s Magic in the Air site:

”At Virgin Atlantic we love the festive season and so do lots of our customers.

So this year, we wanted to see how much ‘festive magic’ our customers and employees are creating around the world.

Partnering with our friends at Microsoft, we're using cloud based Dynamics social analytics software to calculate the volume and sentiment of social posts on platforms like Facebook and Twitter. We’re analyzing the posts for positive mentions of keywords like ‘Christmas,’ ‘magic’ and ‘reindeer.’ So we can understand how much of that festive magic is being generated every day until 7January, 2015.

We're doing this in a totally anonymous way, and we're not storing any personal information. We just want to understand how much magic we're collectively creating during this period.”

What a fun and festive way to show software in action, and use technology to light up the holiday season.

You Might Also Like

Santa Lands on a Virgin Atlantic Plane with 4D Technology

The Microsoft Story

The Mission of Microsoft Enterprise Services

Categories: Architecture, Programming

Neo4j 2.1.6 – Cypher: FOREACH slowness

Mark Needham - Sun, 12/28/2014 - 05:28

A common problem that people have when using Neo4j for social network applications is updating a person with their newly imported friends.

We’ll have an array of friends that we want to connect to a single Person node. Assuming the following schema…

$ schema
Indexes
  ON :Person(id) ONLINE
 
No constraints

…a simplified version would look like this:

WITH range (2,1002) AS friends
MERGE (p:Person {id: 1})
 
FOREACH(f IN friends |
  MERGE (friend:Person {id: f})
  MERGE (friend)-[:FRIENDS]->p);

If we execute that on an empty database we’ll see something like this:

+-------------------+
| No data returned. |
+-------------------+
Nodes created: 1002
Relationships created: 1001
Properties set: 1002
Labels added: 1002
19173 ms

This took much longer than we’d expect so let’s have a look at the PROFILE output:

EmptyResult
  |
  +UpdateGraph(0)
    |
    +Eager
      |
      +UpdateGraph(1)
        |
        +Extract
          |
          +Null
 
+----------------+------+---------+-------------+--------------------------------------+
|       Operator | Rows |  DbHits | Identifiers |                                Other |
+----------------+------+---------+-------------+--------------------------------------+
|    EmptyResult |    0 |       0 |             |                                      |
| UpdateGraph(0) |    1 | 3015012 |             |                              Foreach |
|          Eager |    1 |       0 |             |                                      |
| UpdateGraph(1) |    1 |       5 |        p, p | MergeNode; {  AUTOINT2}; :Person(id) |
|        Extract |    1 |       0 |             |                              friends |
|           Null |    ? |       ? |             |                                      |
+----------------+------+---------+-------------+--------------------------------------+

The DbHits value on the 2nd row seems suspiciously high suggesting that FOREACH might not be making use of the Person#id index and is instead scanning all Person nodes each time.

I’m not sure how to drill into that further but an alternative approach is to try out the same query but using UNWIND instead and checking the profile output of that:

WITH range (2,1002) AS friends
MERGE (p:Person {id: 1})
WITH p, friends
UNWIND friends AS f
MERGE (friend:Person {id: f})
MERGE (friend)-[:FRIENDS]->p;
+-------------------+
| No data returned. |
+-------------------+
Nodes created: 1002
Relationships created: 1001
Properties set: 1002
Labels added: 1002
343 ms
EmptyResult
  |
  +UpdateGraph(0)
    |
    +Eager(0)
      |
      +UpdateGraph(1)
        |
        +UNWIND
          |
          +Eager(1)
            |
            +UpdateGraph(2)
              |
              +Extract
                |
                +Null
 
+----------------+------+--------+-------------------------+--------------------------------------+
|       Operator | Rows | DbHits |             Identifiers |                                Other |
+----------------+------+--------+-------------------------+--------------------------------------+
|    EmptyResult |    0 |      0 |                         |                                      |
| UpdateGraph(0) | 1001 |      0 | friend, p,   UNNAMED136 |                         MergePattern |
|       Eager(0) | 1001 |      0 |                         |                                      |
| UpdateGraph(1) | 1001 |   5005 |          friend, friend |            MergeNode; f; :Person(id) |
|         UNWIND | 1001 |      0 |                         |                                      |
|       Eager(1) |    1 |      0 |                         |                                      |
| UpdateGraph(2) |    1 |      5 |                    p, p | MergeNode; {  AUTOINT2}; :Person(id) |
|        Extract |    1 |      0 |                         |                              friends |
|           Null |    ? |      ? |                         |                                      |
+----------------+------+--------+-------------------------+--------------------------------------+

That’s much quicker and doesn’t touch as many nodes as FOREACH was. I expect the index issue will be sorted out in future but until then UNWIND is our friend.

Categories: Programming

Re-read Saturday: Empowering Employees for Broad-Based Action, Leading Change, John P. Kotter Chapter Seven

A trail map enables hikers to choose their own path!

A trail map enables hikers to choose their own path!

Change is a fact of life.  John P. Kotter’s book, Leading Change, defines his famous eight-stage model for change. The first stage of the model is establishing a sense of urgency. A sense of urgency provides the energy and rational for any large, long-term change program. Once a sense of urgency has been established, the second stage in the eight-stage model for change is the establishment of a guiding coalition. If a sense of urgency provides energy to drive change, a guiding coalition provides the power for making change happen. A vision, built on the foundation of urgency and a guiding coalition, represents a picture of a state of being at some point in the future. Developing a vision and strategy is only a start, the vision and strategy must be clearly and consistently communicated to build the critical mass needed to make change actually happen. Once an organization wound up and primed, the people within the organization must be empowered and let loose to create change.

I view the stages the precede stage five to be a build up to the beginning of the main course. Each step is incredibly important and ignoring any of the steps will lead to problems and failure.  However, if the change you are attempting to generate is to be broad based and long lasting, you will need to empower people.  In this chapter Kotter discusses removing barriers to empowerment. Kotter singles out four categories of barriers for examination:

  1. Structural – Organizational structure defines how the lines of authority and responsibility are constructed in order to deliver the organization’s products and services. An organization’s structures are generally developed to effectively and efficiently deliver services and products based on a specific way of working. Structures are built to guide and control work AND to resist change. Managers often defend the current structure and their own base of power leading to specialization. Specialization generates silos; fragmenting the work so that to deliver a product or service, many handoffs are required.  Handoffs slow the flow of information and communication, which accentuates the need to foster stable processes over innovation. Breaking through structural barriers requires a constant sense of urgency and senior management oversight and dedication.
  2. Skills – Change often requires reskilling employees who have spent years acquiring knowledge and skills and believe they have been successful. The act of having to acquire new skills and change what has worked in the past generates fear of the future and resistance. People fear change they do not think will benefit them or at least can’t predict will be positive. A training strategy needs to couple the experience and concepts to convince those involved with the change that they will be successful. Training to reskill employees must be designed to combat resistance and to address adult learning (see Training Strategies for Transformations and Change: Synthesis).
  3. Systems – Systems of all types need to change to empower and support employees in making change. Systems include information technology applications (e.g. customer relationship systems and logistics systems) and business processes (e.g. objectives, hiring processes, promotions). Changes to the process and systems are critical to making change possible and then supporting change.
  4. Supervisors – Not all supervisors and middle managers will support the vision and strategy for change adopted by the organization. When these leaders baulk at empowering their employees, change often grinds to a halt. Kotter suggests that you should confront the recalcitrant with honest dialog. I would add that that when the dialog occurs (the earlier the better) that the power that urgency, vision and constancy of purpose be used to get holdouts on the change train. Employees with supervisors that actively resist the change will never feel safe enough to be empowered.

Empowering employees generates power and action.  They are required to transform a vision and strategy into something tangible rather than something ethereal.  Without empowered employees, change fails.


Categories: Process Management

Five Problems That Impact Testing Effectiveness and Efficiency: #5 Process

Apparently the cleaning crew flows a process

Apparently the cleaning crew flows a process

Developing or maintaining a piece of software requires a fairly complicated set of processes, including processes for collecting requirements, designing, coding, verifying and validating a solution. All of the processes need to work together well or they risk impacting the quality of the delivered product. Process problems tend to be most severe when testing and engineering processes are mismatched, organizations embrace a one-size-fits-all testing solution or ad-hoc testing processes (gag).

  • Mismatched processes – Testing is a collaborative process requiring communication between everyone involved in developing software. When development and testing processes are not synchronized, the chance of miscommunication increases.  For example, consider the communication problems that would ensue if the developers were using Agile techniques while the testers were using waterfall techniques. Agile development techniques would be focused on delivering functional code rather than omnibus requirements or design documents that are often used to drive waterfall testing. Whether Agile, waterfall, RUP or some other framework if testing and development have not found a mechanism to synchronize how they work together, defects will make it to production.
  • One-size-fits-all testing solutions – Every project has its own set of nuances and risks. The testing solution for each project needs to be tailored to meet the specific needs of the project. A one-size-fits-all solution will tend to overemphasize specific types of testing (e.g. functional testing, system testing or integration testing) when another type may need emphasis.  For example, recently I observed a large program that initially failed on delivery because integration testing was not part of the standard process the firm used.
  • Ad-hoc testing – Ad-hoc testing (just winging it) went out of style as soon as someone thought about the quality of the code being delivered, it never worked and never will. Just don’t do this.

Development is a dance of multiple inter-related processes. Regardless of whether the project uses the team uses a mixture of extreme programming, test-driven development, black-box testing or exploratory testing the processes need to work together. Synchronized and compatible development and testing processes are critical for effectively and efficiently developing. Agile techniques leveraging cross-functional teams, that include developers and testers, put teams in the best position to ensure a synchronized process.


Categories: Process Management

Productivity Books to Help You Know More, Be More, and Achieve More

I’ve put together a roundup of the best productivity books that have helped me get better results in work and life.  It contains many of the same books that I recommend to people and teams that I mentor.  Here is the list:

Productivity Books

It has a lot of books.  To be productive, it takes a lot of skills, and a lot of self-mastery.  And, you never know which book is going to do it for you.

I organize the productivity books in a scenario-based way:

  • Top 10 Best Productivity Books
  • Getting Started
  • Advanced Productivity
  • Action
  • Delegation
  • Drive, Energy, and Motivation
  • Focus
  • Goals
  • Learning and School
  • Procrastination
  • Teams and Organizations
  • To-Do Lists
  • Work-Life Balance

At the end of the list, I included all the books in a simple, flat A-Z list so you can quickly check against your own productivity book collection to see if I have mentioned books that you don’t have or don’t know about.

I’ve put this list of productivity books together to give you an unfair advantage.   Competition can be fierce.  Remember that the best person to always compete against is you—find ways to be better, faster, or cheaper, when it comes to making things happen.  It’s how you stay in the game, and it’s how you change your game.

In fact, productivity is a backbone for surviving and thriving.  Yeah, it’s a big deal.

Also, bear in mind that the big idea behind extreme productivity, or effective productivity is to focus on learning and growth.   If you have a growth mindset, you’ll win in the long-run, because you’ll get better over time, and you can compound your effort.  Also, learn to embrace the effort, and to love the work you do, or love the way you do it.  

Your work is the ultimate self-expression, and the legacy you leave behind, can be an inspiration for yourself, as well as for others.

My Productivity Books page will be a living catalog of the books I draw from, and it’s part of my bigger Great Books collection, where I share the world’s best books for insight and action on business, career, leadership, personal development, and more.

I know there are a lot of productivity books on my list.   If I can only recommend one, I start people off with Getting Results the Agile Way.   I wrote it specifically to help people get better results in work and life with a simple system I developed over time in extreme scenarios.   It integrates proven practices for personal productivity, as well as positive psychology, project management, sports science, and more in terms of achieving high-performance with flow.  And, it’s easy to get started (Here is the Agile Results QuickStart.)

I believe in the power of books to change lives.   Productivity is just one area, but it’s an area that impacts all the other major areas of our life.

If you can master productivity, you can know more, be more, and achieve more.

And, if you balance that with living your values, making an impact, and enjoying the journey, that is the key to living la vida buena.

Categories: Architecture, Programming

The Work/Life Balance

Software Requirements Blog - Seilevel.com - Fri, 12/26/2014 - 17:30
Back in the day when I was an intern, I worked for a large corporation that promoted this idea of a “Work/Life Balance.” Most of my fellow interns thought it was just a catchy buzz-phrase or a sales pitch, but I have always embraced the idea. As the child of two work-a-holics, I am VERY […]
Categories: Requirements

Five Problems That Impact Testing Effectiveness and Efficiency: #4 Capability

In order to participate you have to be capable.

In order to participate you have to be capable.

Testing effectiveness and efficiency will suffer if the organization or team does not have the capability to test well. Testing with the proper level of capability is akin to trying to drive from Cleveland, Ohio to Washington, DC in a car with four flat tires.  It could be done, but at what cost?  Capabilities include the number of testers, clarity of responsibilities, expertise, tools and environments.  Problems in any of these categories will affect the effectiveness and efficiency of testing.

  • The number of testers – There is no fixed ratio of testers to developers however too few testers will cause corners to be cut. The development methods used, amount of test automation available, application criticality and the ability of others in the organization to augment the ranks of testers will all impact the required staffing level. The business needs and test goals and strategy will also influence staffing levels for testers.
  • Clarity of responsibilities – The responsibilities for testing in teams can be easily delineated if the team is cross functional with a mix of developers and testers supporting a common delivery goal. Techniques, such as stand-up meetings, are useful for ensuring everyone knows the work they are responsible for completing. As the number of teams increase, ensuring testing responsibilities are understood become more problematic.  Techniques, such as SAFe’s release planning and the role of a release train engineer, can be leveraged as tools to coordinate responsibilities.
  • Expertise – Just drafting anyone to do testing is a recipe for using your clients to find your defects. The core of your testing capabilities needs to be comprised of experienced (both in testing and with the application being tested) and certified testers. The core testers should lead testing efforts, but also act as consultants to support others who also are acting as testers (think cross-functional).
  • Tools – Development frameworks like Agile work best when testing is performed early and often. Making testing a ubiquitous part of the development process requires test automation.  Automation is needed not only for executing tests, but for generating test data, generating code builds, and capturing defects. Good automation will lessen the testing effort burden and increase the effectiveness of testing.
  • Environments – A test environment is the combination of hardware, software and data required to run software tests. Test environments should closely emulate the environment that the software will run in when it is finally installed in production.  Problems in the test environment will generally mask problems that will not be recognized until production.  The expense to implement and maintain test environments often cause organizations to cut corners on the number or makeup of test environments.

A team’s or organization’s testing capabilities are critical factors in the equation of whether testing will be effective and efficient. Capabilities encompass a broad range of factors from people to computer environments.  Being good at one might compensate a bit for weaknesses in another, but in the long run an organization needs strength in all categories testing software


Categories: Process Management

Merry Christmas, 2014

Merry Christmas 2014

Merry Christmas 2014

Eric Sevareid, a CBS news journalist from 1939 to 1977, said, “Christmas is a necessity. There has to be at least one day of the year to remind us that we’re here for something else besides ourselves.” Whether in your day job you gather requirements, write or test code, facilitate teams or lead change Christmas represents a time to reflect on the larger world, reflect and make it better for someone other than yourself. NPR’s Morning Edition on December 24 included a segment discussing research that suggests that generosity is a hardwired human attribute.  The research by Dr. Lara Aknin is an Assistant Professor of Psychology at Simon Fraser University suggests that people feel better about themselves and the world around them when they are generous to others. Christmas is a day of celebration but also a reminder that to feel good about ourselves we need to give of ourselves to others.

Regardless of whether you celebrate Christmas, take the few minutes you would spend reading this blog and reach out to a family member you have lost track of, a co-worker that might be alone on this day or to a friend you have only talked to only on Facebook and say hello. Whether, like Fred in the Dicken’s Christmas Carol, invite your Uncle Scrooge to dinner or just spend a few minutes on the phone reaching out to another fellow human.


Categories: Process Management

Blame Yourself First

Making the Complex Simple - John Sonmez - Thu, 12/25/2014 - 16:00

In this video, I talk about why it is important to take responsibility for things that happen to you instead of blaming others and circumstances. When you choose to blame others and “bad luck” or make excuses for yourself, you give your power away to make a positive change in your situation.

The post Blame Yourself First appeared first on Simple Programmer.

Categories: Programming

Five Problems That Impact Testing Effectiveness and Efficiency: #3 Organizational Management

Expectations and environment affect behavior.

Expectations and environment affect behavior.

When I was a manager of QA (testing), my manager more than once shared the expectation that testing should have found all of the defects in a piece of software before it was put into production. I actually think that expectation found its way into my annual objectives just prior to my changing jobs. Not only is it not possible to find all defects, the responsibility for defect removal must be shared by developers and testers alike. Organizational management can impact test efficiency and effectiveness in many ways, however three are fairly common.

  1. Unrealistic expectations – One of the principles of testing is that exhaustive testing is impossible.  The over-emphasis of removing all defects or perhaps slightly less dangerous – all significant defects – takes the focus away reducing risks. Testers and test managers must use testing and other techniques (reviews, for example) to focus the available time and effort they have on what is important and risky. Developing an understanding of potential impact and possibility of problems (risk) is needed to target testing resources. That is impossible when trying to find all possible problems.
  2. Undervaluing /Underfunding testing – One the indicators of how an organization values test (and testers) is funding. Funding includes people, tools and other resources. Organizations can have enough testers and but not the proper logistics to test effectively or efficiently.  Another common indication that testing is considered a commodity or not a core function is when an organization outsources testing.
  3. Failure to pursue root causes of defects – Testing shows that defects exist (another principle of testing). Testing does not create defects; said another way defects come from somewhere else. The only way to stem the tide of defects is to change how the software is developed by improving the development process (inclusive of people, process and tools) by finding the root cause of defects and then improving the process. If process improvement does not include the development process the rate of defects production will not change. Ignoring the lessons from defects found in testing dooms the organization to repeating the mistakes that led to those defects.

Organizational management can have a direct impact on the effectiveness and efficiency of testing.  The actions that are taken are very rarely because they want buggy software, but rather because they are unsure of the role, scope and goal of testing in the development and maintenance of software.  As a general rule, the role of testing whether through reviews requirements, design and code or by executing cases is to find defects. Software is complex enough that exhaustive testing is either not possible or not cost effective, therefore the goal of testing is to reduce the risk to the users of the software (and to the organization) that defects that will be delivered. The organization has the responsibility to provide the resources and tools needed to meet the goals and strategy of the testing that is needed to meet the organization’s goals.


Categories: Process Management

Quote of the Day - Do It Right the First Time (Update)

Herding Cats - Glen Alleman - Wed, 12/24/2014 - 19:12

Screen Shot 2014-12-23 at 1.17.48 PM

This quote has two interpretations:

  • New ideas from beginners provide many more opportunities for good results than from experts.
  • Experts understand the consequences of untested, unproven, ill conceived ideas on the probability of success for mission critical, high value at risk projects.

I want to thank Tom Peters @tom_peters for stimulating this clarity.

In parallel with this notion of novices know better and experts have limited possibilities is the conjecture that: 

Do it Right the First Time is the dumbest statement ever uttered by a human being

In the absence of a domain and context in that domain, that statement is of little value - a nice platitude with no actionable outcomes.

Here's an example from personal experience. 

Mars Science Laboratory represents the first use of a "soft landing" technique called the Sky Crane maneuver. The sheer mass of Mars Science Laboratory prevented engineers from using the familiar airbags to deliver their rover safely to the martian surface. As rovers become more capable and carry more instruments, they become larger. So, in order to accommodate this advanced mission, engineers designed a sky-crane method that will lower the rover to the surface.

This mission was built and tested by the same people who built and flew most of the other Mars missions, right here in town. The decent shield, engines and other processes had to work the first time as a system and could not be tested as a system, since the final testing could only take place on Mars.

"Courisity relies on untried Sky Crane for Mars descent

So in this case (domain) it has to work the first time, or the mission is lost.

The consequences failing for the first time to reach your audience and gets a round of applause at a conference on a new topic may mean not being invited back.

So when we read all those posts about agreeing with the do it right is the worst things that ever happened, ask if those posters have ever worked on a mission critical must work project where billions are at risk? Maybe lives aren't a risk on Mars lander, but Nuke Power start ups, weapons plants cleanups with loose plutonium laying on the floor, off shore unattended gas platforms, ABM intercept missiles, and the like are actually in the domain of do it right the first time.

Those who use the terms fail often may not have experienced these high value at risk conditions, where failure is actually not an option. Lovell's comment to his ground partner during their joint talk at a PMI conference was Gene says Failure was not an option. I'd have to say Success was our only option.

Gene Kranz Glen Kevin and Lovell

Succeeding on the first try is mandated in many domains. Doesn't mean you haven't prepared in depth for that first try. But it is naive at best to think that failure is to be tolerated in the absence of a domain and context that assesses the consequences of that failure.

Those who suggest  fail often and you'll learn more in the absence of a domain, context, and Value at Risk are just repeating a platitude in the absence of witnessing the BBR aftermath of failure

Our past experiences informs our current world view, mine is from mission critical - literally  do or die - experiences. So I'm jaded on making over generalized statements in the absence of domain and context.

A good example of this do it right the first time can be found in the history of RFETS, where the consequences of failure were very high. One of the brilliant strategies of the first CEO was to hire Navy ship and submarine Captains who understood those consequences and behaved accordingly when faced with a high value at risk situation.

Making the impossible possible from Glen Alleman

So when you hear I've tried this, maybe you should try it as well. Or just try it, when you've failed you'll be better for it. Ask if that speaker has any experience outside his own anecdotal domain to make a credible assessment of the applicability of his suggestion?

From https://blog.slideshare.net/2014/12/12/entrepreneurial-expertise-guy-kawasakis-3-must-see-decks/

Related articles What is Governance? Complex Project Management Is Programming the Same as Software Engineering? The Myth and Half-Truths of "Myths and Half-Truths"
Categories: Project Management

Santa Lands on a Virgin Atlantic Plane with 4D Technology

Microsoft and Virgin help land Santa on top of a plane at 30,000 feet.  If you’ve been wondering where Santa’s been, he landed on top of a Virgin Atlantic plane and did a photo shoot with the passengers.

Microsoft teamed up with Richard Branson and Virgin Atlantic to bring the magic of Christmas to life.  In the world’s first 4D experience in flight, Santa Claus appears to land on top of a Virgin Atlantic plane at 30,000 feet. 

How’s that for some fancy flying with modern technology?!

Each passenger was also given a Windows tablet so they could track Father Christmas and chat with him during the flight.

Here’s the video of Santa landing on top of the plane and visiting with the passengers:

Video: Santa Lands on Top of a Virgin Atlantic Plane at 30,000 Feet

Here are a few scenes that show Santa in action …

Here’s one of Santa’s reindeer peering down into the cabin from on top of the plane:

image

Here’s Santa peering down into the cabin from above the plane before he goes inside:

image

Santa sees somebody he recognizes:

image

Santa boards the plane and walks the cabin:

image

The kids are excited to see Santa:

image

image

 

Adults are happy, too:

image

image

Santa has time for some photo shoots:

image

image

Santa leaves to get back to his sleigh on top of the plane:

image

Virgin Atlantic and Microsoft wish everybody a very, merry Christmas:

image

Here’s Richard Branson’s post on the story:

Santa Lands on Virgin Atlantic Plane at 30,000 Feet

Merry Christmas to all and to all a good night.

JD

You Might Also Like

10 Big Ideas from a Christmas Carol

25 Holiday Classic Movies and Lessons Learned

Microsoft Cloud Case Studies at a Glance

Categories: Architecture, Programming

Five Problems That Impact Testing Effectiveness and Efficiency: #2 Involvement

 

Riding a horse requires the involvement of the horse!

Riding a horse requires the involvement of the horse!

Effective testing scenarios require a tester to work with users, product owners, business analysts, developers and others to determine whether a deliverable is what it is supposed to be, whether it meets the definition of done and standards of quality. Testing is a collaborative enterprise. Testing is less effective when the right people are not involved in testing. In order to meet the basic level of collaborative involvement for effective testing, testers need interaction with the broad stakeholder community in three broad categories of activity. They are:

  1. Developing requirements – Requirements, whether written as user stories, use cases or paragraphs of text, are a critical input into the testing process. Requirements become the basis of comparison to determine if what is being developed is what the the business wants. Business and technical stakeholders provide the input that becomes the requirements. Testing provides feedback to challenge the assumptions of the stakeholders and development teams as the requirements are formed, groomed and transformed into functional code.
  2. Defining realistic acceptance tests and criteria – A well-formed user story includes not only the story itself, but a set of acceptance criteria. Acceptance criteria provide the development team both with a deeper understanding of how to interpret the story and with a tool to understand when development is complete. Business and technical stakeholders provide the diversity of knowledge to develop relevant acceptance tests and criteria. When testing is a silo’ed task the development team will have to make assumptions that will need to be validated later in the process (later is never better than sooner when it comes to validation). Agile roles such as the product owner and techniques like the Three Amigos are tools to codify involvement.
  3. Participating in reviews, discussions, demonstrations and acceptance testing – I have written a few lines of code, managed a few projects and teams and tested a few projects in my career. In most of those cases a business facing product owner and/or user(s) where involved in validating and verifying the work as it progressed toward completion. I can’t count the number of defects or poor assumptions that were caught and fixed along the way. In those scenarios where real stakeholders did not participate in reviewing, refining and testing the product, the quality was generally lower. Colleagues over the years have expressed similar observations.

When you look in a cube and see a developer or tester reading a user story or use case while typing out a test or perhaps even executing a specific test, it might seem that testing is a solitary event. But you would probably be wrong. What you would have missed is the interaction between developers, testers, product owners that preceded those events, in which knowledge and perspectives were shared. You would have also missed the involvement of users, product owners, developers and stakeholders to review the results so that what gets delivered is not only technically correct, but also has business value. Without involvement, testing provides far less value than possible.


Categories: Process Management