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!

Process Management

SPaMCAST 429 - Ryan Ripley, Agile Certifications Good and Bad Influences

Software Process and Measurement Cast - Sun, 02/05/2017 - 23:00

The Software Process and Measurement Cast 429 is a  special event. Ryan Ripley (who appeared on SPaMCAST 404 and is the host of the Agile for Humans Podcast) and the I recently connected virtually to discuss the role and impact of certifications on the Agile movement.  Certifications are an important gating tool in the job market and may provide evidence that people are keeping up to date with changes in the industry.  Or certifications could represent the calcifying of boundaries that make the adage ‘inspect and adapt’ a thing of the past.  We discuss!  We are going to release the audio on both our podcasts serially, the SPaMCAST today and then Agile for Humans on the 13th!  

Make sure both Agile for Humans and the Software Process and Measurement Cast are part of your weekly rituals!  

Mr. Ryan Ripley has worked on agile teams for the past 10 years in development, scrum master and management roles. He’s worked at various Fortune 1000 companies in the medical device, wholesale, and financial services industries.

Ryan is great at taking tests and holds the PMI-ACP, PSM I, PSM II, PSE, PSPO I, PSD I, CSM, CSPO, and CSP agile certifications. He lives in Indiana with his wife Kristin and three children. Ryan blogs at ryanripley.com and hosts the Agile for Humans Podcast. You can also follow Ryan on Twitter: @ryanripley

Re-Read Saturday News

This week we tackle Chapter 2 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 2 Dweck provides a deeper dive into fixed and growth mindsets.  The chapter begins with Dweck’s relating how the discovery that there were two meanings to the word ‘ability’ shaped the work.  The first definition for ability is a fixed capability that needs to be proven (continually); the second definition is that an ability is a capability that can be developed through learning. The distinction between two definitions are at the heart of the behavioral differences between the growth and fixed mindsets.  Those that believe that abilities can be developed will seek stretch goals and view failures as learning opportunities, while those with a fixed mindset will have a very different point of view.  

Every week we discuss the chapter then consider the implications of what we have “read” from the point of view of someone pursuing an organizational transformation and also how to use the material when coaching teams.  

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The Software Process and Measurement Cast 430 will shift back to the magazine format with an essay on product owners.  The product owner role  is nuanced and sometimes hard.  The essay will help you sort things out.  

We will also have columns from Steve Tendon with another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) and an installment of Gene Hughson’s Form Follows Function Blog (the same Gene, that Ryan called out on this week’s cast).

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Mindset: The New Psychology of Success: Re-Read Week 3,Chapter 2 – Inside the Mindsets

Mindset Book Cover

Today we tackle Chapter 2 in Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along). In Chapter 2 Dweck provides a deeper dive into fixed and growth mindsets.  The chapter begins with Dweck’s relating how the discovery that there were two meanings to the word ‘ability’ shaped the work.  The first definition for ability is a fixed capability that needs to be proven (continually); the second definition is that an ability is a capability that can be developed through learning. The distinction between two definitions are at the heart of the behavioral differences between the growth and fixed mindsets.  Those that believe that abilities can be developed will seek stretch goals and view failures as a learning opportunities, while those with a fixed mindset will have a very different point of view.

As we dive into examples of the distinctions, keep in mind that mindsets are beliefs, and while beliefs are sticky, they can change based on many different stimuli. I would add that until beliefs are challenged and changed they have an impact on how we behave even if they are at odds with evidence or the norms of the team or organization.

In Chapter 2, Dweck illustrates the difference between a fixed and growth mindset using several attributes common in the team and business environment.   For example, for those with a fixed mindset, the operational definition of their personal success relates to proving they are smart and capable.  Alternately those with growth mindsets define success in terms of stretching and growth.

Another illustration of a behavior demonstrated by someone with a fixed mindset is the avoidance of taking risks that expose their deficiencies.  When someone avoids exposing their deficiencies, they will tend to avoid anything they are not currently good at so they do not have to deal with their deficiencies.  This avoidance of challenges not only affects the individual by potentially constraining their future because they will accept of even get fewer opportunities to advance but just as importantly it can impact the ability of the team to deliver outside-the-box solutions.

Another reason that mindsets matter is because our mindset influences who we have around us. The manager who collects “yes-men” as subordinates is a reflection of a fixed mindset seeking positive feedback that props up their ego.  The opposite point of view is the growth mindset manager that fosters an environment in which critical feedback is viewed as a tool to improve performance.

Other differences highlighted in the chapter include the idea that those with a fixed mindset will tend to repeat concepts and strategies that have been successful in the past with little regard to context.  It is an example of ‘the answer seeking the proper question’ syndrome.  Whereas those with a growth mindset search begin by evaluating the context and then trying new ideas and concepts.  Tests provide another illustration of how the different mindsets approach information/data.  For those with a fixed mindset, tests define who you are whereas those with a growth mindset will approach the results as of a test as a single data point. The value of an individual test is powerful.  Many organizations I am aware of use physiological and capabilities tests to screen applicants. However, rarely do these tests attempt to judge whether they are capturing more than just a current state or whether the applicant is committed to continuous growth.

Entitlement is also a marker of a fixed mindset.  In this circumstance, because they perceive that traits are fixed when they succeed they feel a sense of superiority.  That sense of superiority reinforces their perception that their traits are better than other people’s traits and therefore they have they are entitled to succeed based on their given traits.

Dweck provides further elaboration in Chapter 2 discussing how failure is interpreted between the mindsets.  In a fixed mindset failure defines, while failure represents a challenge and learning experience in a growth mindset.  Listen to people as they rationalize failure, those who have the propensity to blame others generally fall into a fixed mindset.

One of the final areas examined in the chapter is the how the two mindsets perceive effort.  Dweck suggests that those with a fixed mindset perceive the need to work hard at being good as a lack of talent.  A true genius should be great nearly instantaneously.  Someone with a growth mindset sees effort as having a transformative power.  The suggestion that you can become an expert by spending 10,000 hours of study on a topic is a reflection of a growth mindset.

Near the end of the chapter in a Q&A section, Dweck makes a couple of very important points.  The first is that people are often a mixture of mindsets.  Whole people fall on a continuum.  For some areas of their life they may be more fixed and in others more growth oriented.  Secondly, the effort is not the only attribute that leads to success.  While success with a set of constraints will always make a person improve the constraints will also influence success. For example, a person can study programming for 10,000 hours, but if they don’t have a computer to program they will never get any feedback and never successfully execute a program.

Chapter 2 from a coach’s perspective

At the level of transforming an organization, it is important to begin by assessing the overall organizational culture.  While Dweck is describing mindsets at person level, we can observe the same basic traits when observing organizational culture.  For example, I have observed many organizations that view failures as career-limiting events (or worse).  I remember once during my career when a project team was summarily terminated by a CEO when the first attempt to deploy a relational database application had performance issues.  In the end, the test environment and the production environment had been tuned differently.  33 people lost their jobs in 15 minutes.  No one ever tried to innovate on a large scale again and in less than five years the firm failed.  A transformation agent needs to be able to profile the organization and build a path for change that reflects how the organization perceives they grow their capabilities.  Often in organizations that are innovation adverse (rarely will you hear an organization ever say they are innovation adverse, you need to observeask for stories), it is better to pursue incremental change rather than large-scale transformations. Note changing an organization’s overall culture will require addressing the mindset issue, we address organizational culture change later in the year.

At a team level, a coach can find nearly limitless applications of mindset both in a tactical and longer term manner.  In the short term, a coach should understand each team member’s mindset.  The coach can use that knowledge to help leaders and team members better understand the mixture of work a team should accept and who will be better suited for different roles. In the longer term, a coach can use his or her understanding of the mindsets on the team to construct exercises and scenarios to help shift composition of mindsets on a team.  In the end, every team will have members that fall somewhere on the mindset continuum and that probably is par for the course.

Previous Entries of the re-read of Mindset:


Categories: Process Management

Being an Agile Security Officer: pwn the process

Xebia Blog - Sat, 02/04/2017 - 20:15
This is the third part of my 'Being an Agile Security Officer series'. As mentioned in my previous blog, in the Agile world the Product Owner is the person who translates business and customer desires into work items for the teams. To do this, product owners have several techniques and means at their disposal. In

Product Owner Role Compared to the Sponsors Role

Super Sponsor

Super Sponsor

The product owner is the voice of the customer and performs a significant of a number of activities, including acting as a conduit/facilitator for communication between the team and the outside world.  Other activities include: defining and elaborating stories, prioritizing the backlog and accepting work when the team completes a story.  The product owner’s role is related or influenced by the sponsor’s roles (sometimes known as executive or project sponsor).  The sponsor is the person that has overall responsibility and accountability for a piece of work.  The sponsor champions the project based on whether the work fits the business’s needs and overall strategy, finds and secures the budget and has the overall responsibility for the work to deliver the promised value. This is true even though he or she will probably never write a line of code or test.  Sponsors empower the product owner to act for them on a more tactical basis.  A comparison of how the sponsor’s typical roles translate to the product owner is shown below:

table-2
The role of the sponsor and the role of the product owner are different and require separate points of view.  The sponsor owns the purse and faces the outside world while the product owner is more focused on the team.  While the roles are separate in small organizations the person playing the role can be the same person; however, in that case split personalities will be highly useful.


Categories: Process Management

How to create your own Lint rule

Xebia Blog - Thu, 02/02/2017 - 08:12
When you are part of a multi-team project in Android, it becomes relatively hard to have a common understanding of how components should be used. This is where Android Lint can help you! In this blog we will show you how you can write your own Lint rules and test them. As an example, we

Run Functional (Coded) UI Tests in your VSTS Release Pipeline

Xebia Blog - Wed, 02/01/2017 - 17:08
Today I was trying to run some CodedUI test from my VSTS Release pipeline. The process is quite straightforward but there were some tiny catches I’d like to share with you Let me first show the pipeline I have created First of all, WINRM. It is always a search for me to see what’s wrong.

The Sweet Software Architecture Spot

From the Editor of Methods & Tools - Wed, 02/01/2017 - 08:54
Software developers keep looking to CQRS as a software architecture to boost performance. But the more I work with companies the more I discover there’s a sweet spot where Theory of Constraints, Kanban, CQRS, Domain-Driven Design, EventStorming and UX blend together to solve ‘the really real problems’. Once you’re there, a land of opportunities ready […]

The Product Owner and ATDD

264237296_864c89a913_z

Product owners act as a conduit between the business and/or customers and the team.  As part of that role the product owner defines (or at least participates) in the definition of the user stories.  The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner integral participates in writing the acceptance criteria for users stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on continuous basis in order to guide the work and the culture.Adoption of acceptance test driven development (ATDD) is an excellent method of instantiating the product owner’s role of both shaping the vision for the team and influencing the quality the work a team delivers.

The Test Obsessed blog states “Acceptance Test Driven Development is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.” The product owner is the central cog in the ATDD process that we have examined in an earlier essay (Acceptance Test Driven Development).  At a high level, ATDD begins by generating a set acceptance test cases for the user stories as they are defined and refined.  The cases or examples are done before coding on the story begin. The cases are a type of example that ensures everyone on the team has the same understanding of what is being built and provide a mechanism for understanding what the customer expects. ATDD provides the product owner and team a path to ensure that the right things are getting built.

Acceptance tests written in advance of coding will always provide additional depth to a user story or the requirements which further supports delivering a quality product.  ATTD is a development technique, a testing technique and collaboration technique. The acceptance cases begin life as a tool to develop shared insight amongst the then transitions into a tool to provide input that is useful for developing the code and finally as the expected results for acceptance testing. The product owner acts as the voice of the customer and controls the flow of the process through their ownership of the backlog (defining, prioritizing, and accepting results). As the voice of the customer and an interface to the business, the product owner has to answer for what gets done and how well it gets done.  ATTD is a tool for the product owner to build quality into the Agile process.

 


Categories: Process Management

The Product Owner and ATDD

264237296_864c89a913_z

Product owners act as a conduit between the business and/or customers and the team.  As part of that role the product owner defines (or at least participates) in the definition of the user stories.  The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner integral participates in writing the acceptance criteria for users stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on continuous basis in order to guide the work and the culture.Adoption of acceptance test driven development (ATDD) is an excellent method of instantiating the product owner’s role of both shaping the vision for the team and influencing the quality the work a team delivers.

The Test Obsessed blog states “Acceptance Test Driven Development is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.” The product owner is the central cog in the ATDD process that we have examined in an earlier essay (Acceptance Test Driven Development).  At a high level, ATDD begins by generating a set acceptance test cases for the user stories as they are defined and refined.  The cases or examples are done before coding on the story begin. The cases are a type of example that ensures everyone on the team has the same understanding of what is being built and provide a mechanism for understanding what the customer expects. ATDD provides the product owner and team a path to ensure that the right things are getting built.

Acceptance tests written in advance of coding will always provide additional depth to a user story or the requirements which further supports delivering a quality product.  ATTD is a development technique, a testing technique and collaboration technique. The acceptance cases begin life as a tool to develop shared insight amongst the then transitions into a tool to provide input that is useful for developing the code and finally as the expected results for acceptance testing. The product owner acts as the voice of the customer and controls the flow of the process through their ownership of the backlog (defining, prioritizing, and accepting results). As the voice of the customer and an interface to the business, the product owner has to answer for what gets done and how well it gets done.  ATTD is a tool for the product owner to build quality into the Agile process.

 


Categories: Process Management

The Product Owner and ATDD

264237296_864c89a913_z

As we have seen, product owners act as a conduit between the business and/or customers and the team. The product owner’s role encompasses not only the definition of what gets done and when, but also the level of quality of what gets delivered.  One of the facets of the role affecting quality comes when the product owner participates in writing the acceptance criteria for user stories.  Acceptance criteria are part of well-formed user stories and are crafted early in the life cycle when stories are generated and refined as they are groomed.  The product owner role provides another check on quality and occurs when the product owner uses his or her authority to accept completed stories.  I don’t want to suggest that the product owner is only active at the start and end of a sprint or iteration. The product owner interacts with the team on a continuous basis in order to guide the work and the culture. Adoption of acceptance test-driven development (ATDD) is an excellent method of instantiating the product owner’s role in both shaping the vision for the team and influencing the quality of the work a team delivers.

The Test Obsessed blog states, “Acceptance Test Driven Development is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.” The product owner is the central cog in the ATDD process that we have examined in an earlier essay (Acceptance Test Driven Development).  At a high level, ATDD begins by generating a set acceptance test cases for the user stories as they are defined and refined.  The cases or examples are done before coding on the story begins. The cases are a type of example that ensures everyone on the team has the same understanding of what is being built and provide a mechanism for understanding what the customer expects. ATDD provides the product owner and team a path to ensure that the right things are getting built.

Acceptance tests written in advance of coding will always provide additional depth to a user story or the requirements which further supports delivering a quality product.  ATDD is a development technique, a testing technique, and collaboration technique. The acceptance cases begin life as a tool to develop shared insight amongst the team then transitions into a tool to provide input that is useful for developing the code and finally as the expected results of acceptance testing. The product owner acts as the voice of the customer and controls the flow of the process through their ownership of the backlog (defining, prioritizing, and accepting results). As the voice of the customer and an interface to the business, the product owner has to answer for what gets done and how well it gets done.  ATDD is a tool for the product owner to build quality into the Agile process.

 


Categories: Process Management

Building, testing and deploying precompiled Azure Functions

Xebia Blog - Tue, 01/31/2017 - 16:00
Azure functions are great to build small specialized services really fast. When you create an Azure Functions project by using the built-in template from the SDK in Visual Studio you’ll automatically get a function made in a CSX file. This looks like plain old C# but in fact it is actually  is C# Script. When

An Agenda for the Sprint Review

Mike Cohn's Blog - Tue, 01/31/2017 - 16:00

The most discernible activity during a sprint review is a demonstration of the functionality built during the sprint. But, a good sprint review includes more than just a demo. Let’s take a look at an agenda for the review.

Welcome Participants & Set the Stage for the Sprint Review

The product owner starts by welcoming everyone to the sprint review. This can be as simple as saying, “Thank you for being here.”

If participants are unfamiliar with one another, the product owner may have attendees briefly introduce themselves. Introductions are generally a good idea at the start of a new product development initiative. The product owner knows that Joe from Marketing is Joe from Marketing but team members may not.

Introductions are also helpful if it is common for an occasional new participant to attend sprint reviews. Perhaps Joe from Marketing will only attend two reviews following the sprints in which the team worked on marketing-related features.

Introductions should be kept extremely short. “Hi, I’m Mike and I’m a developer. I’ve been working on the shopping cart features,” is plenty. In some cases, “I’m Mike and I’m a developer,” would be enough. But once a team reaches a certain size, it can be helpful for stakeholders to hear a few words to let them know who has been doing what.

After an initial welcome by the product owner and any needed introductions, the product owner can share any ground rules or expectations for the sprint review. For example, some product owners find it necessary to state the need to keep the meeting civil. If someone doesn’t like how a feature was implemented it’s fine to say so, but don’t call the implementation “stupid” or so on. Yes, we all should know things like this anyway, but sometimes people need to be reminded.

Depending on the number of attendees and many other factors, a product owner might also state that while she is looking for feedback on what was built, the sprint review itself will not be the time to redesign features.

With the welcome message, introductions, and ground rules out of the way, it’s time to move onto the next item on the agenda.

State What Will (and Will Not) Be Demonstrated

At this point, many teams dive right in and start demonstrating. Instead, I recommend the product owner present a very brief overview of what will be demonstrated and what will not be.

To avoid a product owner just reading a list of items that participants won’t be able to follow, display something on the monitor or projector being used. Or have printed copies available for those who want one.

I like to prepare this as a Word document and email it to likely review participants at the end of the day before the review. This allows people a chance to see what will be demonstrated. Each person can then intelligently decide whether to attend or not based on what will be shown.

The following table shows the information I like to include for each product backlog item. I recommend putting this list in the order in which items will be demonstrated, although you can change that on the fly as needed during the meeting.

 

Description                                               SIZE    STATUS                                                 DEMO      As a user, I .... 5 Finished

Yes

As a user, I .... 3

Finished but there’s more we could add to the such-and-such part of this.

Yes As a user, I .... 5 We started but there were too many open issues No Bug fix: Update the copyright notice on the About screen 0 Finished No ADDED: As a … 3 We brought this item in when we dropped the item above. Yes

 

The table starts with a description of the item. Put the user story or other description here. Next include the size of the item, usually this will be in story points. Then list the status of the item. Mostly this is whether the item was finished or not, but include anything else that is important to note. Finally, include a column indicating whether the item will be demonstrated or not.

You may wonder why we’d ever have items that the team would not demonstrate. I’ve provided a couple of examples in the sample table. Obviously, the item that was planned into the sprint but dropped cannot be demonstrated. I’ve also shown a simple bug fix that updates one character on one screen--it is not scheduled for demonstration either.

It’s quite possible that one or more participants might ask to see an item that you had not planned to show. When that happens, go ahead and demonstrate the item along with all others. You’re not trying to avoid showing something, you’re just trying to be respectful of people’s time by not showing them things that don’t really need feedback.

Notice in the sample above, I indicated that one product backlog item was added during the sprint. I think it’s a good idea to indicate items added during the sprint so they can be distinguished from those that were planned into the sprint. If adding items happens frequently, consider adding an initial column and putting P (for Planned) or A (for Added) in it.  

You might also want to consider a column at the far right that can be used to indicate whether each item is accepted by the review participants or ready to release or such. Do this if those types of decisions are formally made as part of a sprint review.

Avoid spending too much time on this part of the agenda. The goal here is not to get feedback on the items or to talk about why a planned item was only partially implemented. This is merely a table of contents into the rest of the meeting. After the product owner has presented this list, move onto the main part of the sprint review: the demo itself.

Demo New Functionality

This is the heart of the sprint review. And if you’re already doing sprint reviews, it’s quite possible this is the only part of the agenda you’re doing.

During this portion of the review, proceed down the list of items you’ve previously shown meeting participants. Keep in mind that the purpose of the sprint review is to solicit feedback.

There is no hard rule about who gives the demo. In some cases, a product owner will operate the keyboard. I’d recommend doing that in a review with particularly challenging stakeholders. Other times, though, team members will demonstrate the specific product backlog items they worked on. Just about any approach works fine. So experiment to find the one that works best for your team.

Discuss Key Occurrences

After all completed product backlog items have been demonstrated, discuss key events or problems that occurred during the sprint.

This discussion could be facilitated by either the product owner or Scrum Master. I’ve found both approaches to work equally well. I do, however, have a slight bias toward having the Scrum Master conduct this part of the meeting.

Up until now, in most sprint reviews the product owner will have done a lot more talking than the Scrum Master. So I find it a good balance to have the Scrum Master facilitate this agenda item. Plus, this is often more a discussion of the process than strictly the product, and so it falls a bit more in the domain of the Scrum Master.

Present Upcoming Product Backlog Items

The final item on a sprint review agenda should be a discussion of the next work on the product backlog. Because the purpose of the sprint review is to acquire feedback on the work of the current sprint, this will often influence what will be worked on in subsequent sprints.

If, for example, participants in the review liked the look of the new screens, the product owner may want to accelerate moving other parts of the product to the new design. Or, if participants didn’t like how a feature was implemented, perhaps the next sprint should be spent fixing issues with it instead of moving onto the next items, as might have happened without a sprint review.

The product owner starts this discussion by presenting the next set of potential items from the product backlog. The product owner might say something like, “On the screen, you’ll see what I thought would be our next ten things to work on, but I want to insert such-and-such that came up today. I’ll add that probably as item three.”

The product owner then solicits comments from participants about the proposed next set of items. I do not, however, recommend that the product owner make any prioritization decisions during the sprint review based on these comments. The reasons for this are many. The product owner may need time to think about what was said in the review. Or the product owner may want to get estimates from the team about changes that were requested in the review. And so on. Instead, the product owner solicits opinions during the sprint review and then makes decisions after the meeting.

Conclude the Meeting

Simply wrap up by thanking everyone for participating. Consider thanking the team in whole for the work of the sprint. Consider occasionally praising a team member or two who performed exceptionally well during the sprint. Remind everyone when and where the next review will be held.

After the Sprint Review

Although not part of the agenda for the actual review, someone should enter any new product backlog items into whatever tool the team is using (or post them on the wall if using physical cards).

How Do You Conduct Reviews?

Please let me know how you do your sprint reviews. Do you include anything I didn’t mention? Do you skip some of these steps? Please share your thoughts in the comments below.

 

 

Get Your Free Sprint Review Agenda Poster

First Name

Email Address

ScrumMaster Interview Questions cover

Verbal Turn Indicators For Intercultural Product Owners

Xebia Blog - Mon, 01/30/2017 - 19:30
Jujutsu exams are coming up. One of the things that examiners want to see in jujutsu is the use of go-no-sen, sen-no-sen and tai-no-sen. Go-no-sen means that you respond to an action of your opponent, tai-no-sen means you act simultaneously and sen-no-sen means you take the initiative and act before the opponent has a chance.

A better way (and script) to add a Service Principal in Azure for VSTS

Xebia Blog - Mon, 01/30/2017 - 16:53
From Visual Studio Team Services (VSTS) it’s possible to deploy to an Azure Subscription using an Active Directory Service Principal. The Microsoft documentation refers to a blog post which describes a 3-clicks and a manual way to setup this principal. Although the information on the blog post for the 3-clicks setup is still actual, the script link

Running Powershell Pester unit test in a VSTS build pipeline

Xebia Blog - Mon, 01/30/2017 - 16:34
When you are developing Powershell scripts, creating some unit tests will help you in monitoring the quality of the scripts. Writing some tests will give you some assurance that your code still works after you make some changes. Writing Powershell unit tests can be done with Pester. Pester will enable you to test your Powershell scripts from

Software Development Conferences Forecast January 2017

From the Editor of Methods & Tools - Mon, 01/30/2017 - 15:14
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

3 key ingredients that make you a better developer

Xebia Blog - Mon, 01/30/2017 - 10:21
IT is a booming business, but that doesn’t mean everyone who’s drawn to it will become a great developer. Many students sign up for an IT education for the wrong reasons. I've had classmates who enrolled in IT-related degree programs because they liked gaming or working with computers. Maybe they created a website for a

SPaMCAST 428 – Mark Bojeun, Project and Product Visions

Dr Mark Bojeon

Dr Mark Bojeun

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

One my favorite serial interviewees, Dr. Mark Bojeun, returns to the Software Process and Measurement Cast for a third time (we may need to get him a permanent seat at the table soon).  Mark and I discussed the role and impact of project and product visions on the ability to effectively deliver value.  The vision is an important directional statement that can’t be left to chance!   

Mark has last visited the Software Process and Measurement Cast on SPaMCAST 388 to discuss PMOs as a strategic tool and before then on the  SPaMCAST 280 to discuss  his book, Program Management Leadership: Creating Successful Team Dynamics (Kindle version).

Mark’s Bio:

Dr. Bojeun has more than 20 years of experience in providing strategic management and leadership through portfolio, project and program management. His experience includes developing and managing multi-million dollar portfolios, programs, and projects, facilitating the achievement of strategic objectives, and creating best practice processes for program and project management efforts. Dr. Bojeun has designed and implemented multiple Enterprise Program Management Offices (EPMOs) for domestic and multinational firms and has extensive experience in organizational change management through transformational leadership, strategic support and staff empowerment to management professionals in the development and implementation of organizational vision, mission, objectives, and goals.

Contact Mark on LinkedIn

Re-Read Saturday News

We missed this week due to work!  I was teaching Test Driven Development.  It was an intense class with a great group.  We will get back in the swing of things next week!

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The Software Process and Measurement Cast 429 will be something very special. Ryan Ripley (who appeared on SPaMCAST 404 and is the host of the Agile for Humans Podcast) recently connected virtually to discuss the role and impact of certifications on the Agile movement.  It was a pretty intense discussion!  We are going to release the audio on both our podcasts concurrently on Monday February 6th!  Make sure both Agile for Humans and the Software Process and Measurement Cast are part of your weekly rituals!  

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 428 – Mark Bojeun, Project and Product Visions

Dr Mark Bojeon

Dr Mark Bojeun

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

One my favorite serial interviewees, Dr. Mark Bojeun, returns to the Software Process and Measurement Cast for a third time (we may need to get him a permanent seat at the table soon).  Mark and I discussed the role and impact of project and product visions on the ability to effectively deliver value.  The vision is an important directional statement that can’t be left to chance!   

Mark has last visited the Software Process and Measurement Cast on SPaMCAST 388 to discuss PMOs as a strategic tool and before then on the  SPaMCAST 280 to discuss  his book, Program Management Leadership: Creating Successful Team Dynamics (Kindle version).

Mark’s Bio:

Dr. Bojeun has more than 20 years of experience in providing strategic management and leadership through portfolio, project and program management. His experience includes developing and managing multi-million dollar portfolios, programs, and projects, facilitating the achievement of strategic objectives, and creating best practice processes for program and project management efforts. Dr. Bojeun has designed and implemented multiple Enterprise Program Management Offices (EPMOs) for domestic and multinational firms and has extensive experience in organizational change management through transformational leadership, strategic support and staff empowerment to management professionals in the development and implementation of organizational vision, mission, objectives, and goals.

Contact Mark on LinkedIn

Re-Read Saturday News

We missed this week due to work!  I was teaching Test Driven Development.  It was an intense class with a great group.  We will get back in the swing of things next week!

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The Software Process and Measurement Cast 429 will be something very special. Ryan Ripley (who appeared on SPaMCAST 404 and is the host of the Agile for Humans Podcast) recently connected virtually to discuss the role and impact of certifications on the Agile movement.  It was a pretty intense discussion!  We are going to release the audio on both our podcasts concurrently on Monday February 6th!  Make sure both Agile for Humans and the Software Process and Measurement Cast are part of your weekly rituals!  

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 428 - Mark Bojeun, Project and Product Visions

Software Process and Measurement Cast - Sun, 01/29/2017 - 23:00

One my favorite serial interviewees, Dr. Mark Bojeun, returns to the Software Process and Measurement Cast for a third time (we may need to get him a permanent seat at the table soon).  Mark and I discussed the role and impact of project and product visions on the ability to effectively deliver value.  The vision is an important directional statement that can’t be left to chance!   

Mark has last visited the Software Process and Measurement Cast on SPaMCAST 388 to discuss PMOs as a strategic tool and before then on the  SPaMCAST 280 to discuss  his book, Program Management Leadership: Creating Successful Team Dynamics (Kindle version).

Mark’s Bio:

Dr. Bojeun has more than 20 years of experience in providing strategic management and leadership through portfolio, project and program management. His experience includes developing and managing multi-million dollar portfolios, programs, and projects, facilitating the achievement of strategic objectives, and creating best practice processes for program and project management efforts. Dr. Bojeun has designed and implemented multiple Enterprise Program Management Offices (EPMOs) for domestic and multinational firms and has extensive experience in organizational change management through transformational leadership, strategic support and staff empowerment to management professionals in the development and implementation of organizational vision, mission, objectives, and goals.

Contact Mark on LinkedIn

Re-Read Saturday News

We missed this week due to work!  I was teaching Test Driven Development.  It was an intense class with a great group.  We will get back in the swing of things next week!

Remember to buy a copy of Carol Dweck’s Mindset and read along!

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

Next SPaMCAST

The Software Process and Measurement Cast 429 will be something very special. Ryan Ripley (who appeared on SPaMCAST 404 and is the host of the Agile for Humans Podcast) recently connected virtually to discuss the role and impact of certifications on the Agile movement.  It was a pretty intense discussion!  We are going to release the audio on both our podcasts concurrently on Monday February 6th!  Make sure both Agile for Humans and the Software Process and Measurement Cast are part of your weekly rituals!  

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management